Removing data set exposers and collectors from behavioral design code

ABSTRACT

A computer implemented method removes an exposer and a collector from a design. A first transport is identified in a design that connects to both exposer and collector. The method determines whether a collector output and an exposer input have matching data set type. If the data set type of the collector output matches the data set type of the exposer input, then a second and third transport are substituted in place of the first transport, collector, and exposer. The second transport is connected to a first input transport that had been connected to a collector input and to a first output transport that had been connected to an exposer output. The third transport is connected to a second input transport that had been connected to another collector input and to a second output transport that had been connected to an exposer output.

CROSS-REFERENCE TO RELATED APPLICATIONS

This is a Divisional of application Ser. No. 09/747,602 filed Dec. 22,2000, which in turn is a Continuation, which claims the benefit of U.S.Provisional Application No. 60/258,112 filed Dec. 22, 2000. The entiredisclosure of the prior applications is hereby incorporated by referencein its entirety.

FIELD OF THE ART

The present disclosure generally relates to behavioral synthesis methodsand, more particularly, to removing data set exposers and collectorsfrom behavioral design code.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the various features can beobtained, a more particular description of the subject matter of theinvention will be rendered by reference to specific embodiments whichare illustrated in the appended drawings. Understanding that thesedrawings depict only typical embodiments and are not therefore to beconsidered to be limiting in scope, embodiments will be described andexplained with additional specificity and detail through the use of theaccompanying drawings in which:

FIGS. A1-A3 are diagrams representing examples of select objects in abranching algorithm;

FIGS. B1-B3 are diagrams representing other implementations of selectobjects in a branching algorithm;

FIG. C1 is an illustrative drawing of an example of anotherimplementation of a select object in a branching algorithm;

FIG. C2 is a diagram illustrating a library object referenced by FIG.C1;

FIG. C3 is an illustrative drawing showing connections in a branchingalgorithm associated with select object of FIG. C1;

FIG. D1 is an illustrative drawing showing a top-level polymorphic ADDobject that can be included within a design diagram;

FIG. D2 is an illustrative drawing showing the polymorphic ADD object ofFIG. D1 connected with transports;

FIGS. D3-D8 are illustrative drawings that show the polymorphic ADDbehavior object at various stages of a synthesis process;

FIG. D9 is a diagram illustrating a next level parallel add objectinserted into the design in place of the top level parallel add object;

FIG. D10 provides an illustration of a next level serial add object;

FIG. E1A is an illustrative drawing showing a representation of atop-level cast behavior object;

FIG. E1B is an illustrative drawing showing a portion of an objectlibrary that pertains to cast behavior;

FIG. E1 is an illustrative drawing showing details of a variant castobject;

FIG. E2 is an illustrative drawing showing a variant castup objectreferenced using the castup object of FIG. E1;

FIG. E3 is an illustrative drawing showing a terminal leaf castupobject;

FIG. E4 is an illustrative drawing showing a variant castdown objectreferenced using the top-level castdown object of FIG. E1;

FIG. E5 is an illustrative diagram that pictorially represents ingeneral terms the evolution of the castup behavior object during asynthesis process;

FIG. E6 is an illustrative drawing showing an explicit castdown object;

FIG. E7 is an illustrative drawing showing a representation of theportion of an object library relating to castdown behavior;

FIG. E8 is an illustrative drawing showing a collection of objects;

FIG. E9 is an illustrative drawing showing a portion of the objectlibrary that pertains to the logical function;

FIG. F1 is an illustrative drawing of a portion of an object librarypertaining to an invert equivalent function;

FIG. F2 is an illustrative diagram showing a representation of atop-level invert function;

FIG. F3 is an illustrative diagram representing the variant invertobject;

FIG. F4 is an illustrative diagram showing an atomic invert object;

FIGS. F5-F8 are illustrative diagrams showing an evolution of an invertobject in a design in response to propagation of a nibble data set toits input node;

FIG. G1 is an illustrative drawing that represents several types of dataset exposers and corresponding data set collectors;

FIG. G2 is an illustrative drawing showing a portion of an objectlibrary related to a variant type data set exposer object;

FIG. G3 is an illustrative drawing showing a portion of an objectlibrary related to a variant type data set collector object;

FIGS. H1-H8 provide pictorial representations of the operators of theAxiom system;

FIGS. I1-I5 provide pictorial representations of some special basicoperators of the language;

FIGS. J1-J49 are illustrative diagrams showing topology of a programconstructed in accordance with various embodiments of the invention;

FIG. K1 is a schematic diagram of an inverter;

FIG. K2 is a schematic diagram showing an inverter connected to a stateelement;

FIG. K3 is a drawing showing a behavioral object that includes aninverter object;

FIGS. L1-L2 are diagrams illustrating atomic object resolution rules foran atomic INVERTER operator;

FIGS. L3-L4 are diagrams illustrating atomic object resolution rules foran atomic AND operator;

FIGS. L5-L6 are diagrams illustrating atomic object resolution rules foran atomic OR operator;

FIGS. L7-L10 are diagrams illustrating atomic object resolution rulesfor an Assignment operator;

FIGS. L10-L14 are illustrative drawings showing combined operation ofthe propagate data sets process and the flatten process in reducing avariant polymorphic behavior object into its atomic elements;

FIGS. M1-M3 are illustrative drawings showing a flatten process thatsubstitutes a lower-level object into a design in place of a givencomposite object;

FIG. N1 is a diagram of a source node;

FIG. N2 is a drawing of a process that constructs the hierarchy ofcollector objects;

FIGS. O1-O3 are drawings that illustrate the operation of the removecollector and exposer objects process;

FIGS. P1-P7 shall be used to provide a hypothetical example of such acomputational polymorphic object;

FIGS. P1-P2 are illustrative drawings showing examples of a one bitserial add and a two bit serial add;

FIG. P3 is an illustrative drawing showing a hypothetical computationalpolymorphic add object;

FIG. P4 is a drawing that illustrates the topology of a variant typedata set shift-by-type object;

FIG. P5 is a drawing that shows a topology of a terminal leaf of thevariant shift by type object;

FIG. P6 is a drawing that illustrates the topology of a variant typedata set RCR object; and

FIG. P7 is a drawing that illustrates the topology of a terminal leafRCR object.

DETAILED DESCRIPTION OF THE VARIOUS EMBODIMENTS

Overview of Synthesis Process and High-Level Diagram BehaviorDescription Language

The present invention provides a novel high-level diagram behaviordescription language to implement novel computer software basedsynthesis process. A behavioral synthesis process in accordance with apresently preferred embodiment of the invention transforms a generalizedbehavioral design in a design database into a detailed interconnectionof design objects to implement the behavior. More specifically, the newsynthesis process synthesizes a detailed design to implement a behaviorfrom a high level diagrammatic description of the behavior. In oneaspect of the invention, a behavioral synthesis process of transforms ahigh level block or schematic design topology into a detailed designcomprising an interconnection of design objects that implements the samedesign topology. In a present embodiment, the detailed design comprisesa netlist that can be targeted to hardware. The targeting to hardwarecan be achieved through placement and routing software tools that formno part of the present invention.

In operation, a user creates a diagrammatic representation of thedesired behavior of a design on a computer user interface. Thediagrammatic representation of the design behavior is created usinggraphic objects taken from a library of graphic objects. The graphicobjects in the design are connected so as to create a block or schematicdiagram representing the desired behavior. Graphic objects are connectedto one another with a special graphic object herein referred to as atransport object. The graphic object library includes atomic orprimitive graphic objects, and it includes composite graphic objects.Atomic or primitive objects are graphic objects that cannot bedecomposed into other graphic objects. Composite graphic objects areobjects that are composed of other graphic objects. Thus, arepresentation of a design may include composite graphic objects, whichin and of themselves comprise other graphic objects connected to oneanother by transport objects. Moreover, graphic objects in the librarymay be hierarchically related in object class-like relationships. Forexample, there is an add behavior class in which a top-level graphicobject references lower level graphic objects in the add behavior class.When a top-level add graphic object is inserted into a design, it bringswith it a reference to the lower level graphic objects in the add objectclass.

In another aspect of the invention, a design database comprised ofdesign objects is created automatically as the user creates adiagrammatic representation of the desired behavior on the computer userinterface. That is, as a user creates a diagrammatic representation of adesired behavior on a computer user interface, a corresponding designdatabase is created in a computer readable storage medium. The designdatabase includes at least one design object for each graphic object inthe diagrammatic representation of desired design behavior.Conceptually, the relationship between design objects and graphicsobjects is not a simple one-to-one relationship since many design andgraphics objects are hierarchical, and one high level object may itselfreference one or more other objects in its hierarchy. Thus, the topologyof a diagrammatic representation of design behavior created on acomputer user interface matches a topology of the design in the designdatabase. For each primitive graphic object there is a correspondingprimitive design object. For each composite graphic object there is acorresponding composite design object. A network of graphic transportobject interconnecting other graphic objects in the diagrammaticrepresentation matches a network of design transport objectsinterconnecting other design objects in the design database.

The synthesis process transforms a topology of a diagrammaticrepresentation of desired design behavior into an interconnection ofatomic objects to achieve the desired behavior. In a present embodiment,the synthesis process produces an actual netlist. The synthesis processboth transforms the diagrammatic representation of behavior displayed onthe user interface and the corresponding design topology in the designdatabase. Therefore, the diagrammatic representation of design behavioron the user interface can be used to assess the results and efficacy ofthe synthesis process upon the design topology in the design database.

A new computer language is provided in which a high level block orschematic design topology can be created to represent desired behaviorof a system. A new synthesis process is provided in a detailed designdatabase comprising design objects interconnected to implement a desireddesign can be synthesized from a high level diagrammatic description ofthe desired system behavior. Thus, the detailed behavioral design of asystem can be synthesized directly from a diagrammatic description ofthe desired behavior of the system.

Multi-Threaded Behavioral Synthesis Process

A synthesis process in accordance with a presently preferred embodimentof the invention comprises multiple concurrent threads of execution.These threads or processes are summarized as follows.

Propagate Data Sets

Propagate Information Rate

Generate Constants

Propagate Constants

Flatten Hierarchical Objects

Select Equivalent Function (operates in conjunction with Flatten)

Exposer and Collector Objects

Remove Sourceless and Sinkless Objects

Compress Transports

The threads of execution run concurrently. For each Thread, the basicexecution process is described in general in pseudo code as follows. 1while (cando) {for each object in the database, DO (Thread) } ifanything was done by any Thread to any object in the database, thencando is true;

Basically, each of the threads of execution operates upon designobjects. The threads operate in parallel. That is they operateconcurrently, but they do not necessarily operate on the same designobjects at the same time. For instance, each of the threads mayconcurrently operate on different design objects. Each of the threadscan transform the object that it operates upon in some manner. Forinstance, the flatten thread may substitute a lower level object in anobject class hierarchy in place of a higher level object in the objectclass hierarchy. Such transformations in effect incrementally transformthe design. For example, just to mention a few of many possibleincremental design changes, a new object may be added to a design, anobject may be removed from the design or connections between objects inthe design may be changed. These incremental changes gradually transformthe design as multiple threads of execution simultaneously processdifferent objects of the overall design.

Each of the threads effects a different aspect of the overall synthesisprocess. For instance, the propagate data sets thread propagates dataset types through the design. The flatten hierarchical objects processreplaces high level objects with equivalent lower level objects. Theremove sourceless and sinkless process removes from a design sourcenodes and sink nodes and certain objects connected to such nodes. Thethreads operate independently from each other. However, as the variousthreads execute, the design database is transformed so that objects thatpreviously were not ready to be processed by a given thread subsequentlybecome ready for processing by that given thread. That thread then canprocess such newly ready objects. Moreover, the processing by that giventhread will further transform the design database so that other objectsbecome ready for processing by other yet other threads. For instance,the flatten process cannot be carried out on a variant data set typeobject until explicit type data sets have been propagated to the datainput nodes of that object. Moreover, the operation of the flattenprocess on that object may leave one or more source or sink nodesunconnected, creating an opportunity for the remove sourceless andsinkless nodes thread to operate on such unconnected nodes. Thus, thedesign database is continually modified throughout the synthesis processby the interaction of the various threads of execution.

Multi-Dimensional Recursive “Wavefront” Behavioral Synthesis Process

Graphic transport objects are used to show connections between designobjects in a diagrammatic description of desired behavior. Each graphictransport object in a design diagram corresponds to at least one designtransport object in a corresponding design database. Graphic transportobjects in a design diagram represent the flow of information from onegraphic object to the next in a design diagram. Similarly, designtransport objects represent the flow of information in a correspondingdesign comprising the interconnected design objects in the designdatabase. Thus, transport objects provide an intuitive mechanism wherebya user can comprehend the flow of information through graphic designdiagram and through a corresponding design in the design database.

Transport objects also serve another important role during the synthesisprocess. Specifically, transport objects define the next token (object)to be processed by one or more threads of execution. For instance,assume that in a design, a given transport object connects a firstupstream object to a second variant data set type object. In that case,the data set propagation process propagates (or copies) data set typefrom an output node of the first object to an input node of the giventransport object. Then it propagates the data set type from the inputnode of the given object to the output node of the given object. Next,it propagates the data set type from the output node of the transportobject to the input node of the second object. The data set propagationprocess follows the path through the design demarcated by the transportobject. Similarly, other threads of execution follow paths demarcated bythe transport object in the design. In essence, a transport objectserves as lexical element in during the synthesis (compiler) processthat identifies the next token to be processed. Multiple threads ofexecution described herein use the transport object as a next tokenidentifier.

A diagrammatic behavioral design in accordance with a present embodimentof the invention will comprise a two dimensional network of graphictransport objects that interconnect graphic objects. Consider that adiagrammatic description of behavior in accordance with a currentembodiment involves the interconnection of graphic objects with multipleinput nodes and multiple output nodes. Furthermore, consider that adiagrammatic representation of a complex design may have numerousbranches creating different paths among graphic objects. Branches arecreated with graphic transport objects.

Remember that for each graphic object in such a diagram, there exists atleast one corresponding design object in a corresponding designdatabase. Thus, there exists in the design database a two dimensionalnetwork of design transport objects interconnecting other designobjects.

During the synthesis process, a parallelism in the execution of multiplethreads naturally develops from a combination of the two dimensionalnature of the network of transports and the transport objects in thenetwork serving as next token identifiers. Moreover, it will beappreciated that processing by any given thread of execution does notfollow just one path of execution at a time from object to object in adesign. Rather, the many transport objects in the network of transportobjects in a design can demarcate multiple paths of execution at anygiven time. Thus, for instance, a first thread may first process anobject identified by a transport object on one branch or path throughthe design. Next, the same first thread may process another objectidentified by a different transport on a different path through thedesign. After that, that same first thread may process yet anotherobject identified by yet another transport object on either one of thesesame two paths or on a different path through the design. Consider thateach of multiple processes is proceeding contemporaneously in a similarmanner, processing one object after the next, as identified by thetransport objects in the design. The overall affect is a synthesisprocess flow that is like a wavefront moving through the design.Multiple threads execute concurrently and individually alternate amongdifferent paths demarcated by different transport objects in the twodimensional network of transport objects in the design.

The locus of the synthesis process changes over and over again duringthe synthesis process. As it does so, the multiple threads of executioncollectively move through the design database as if they were awavefront. Each thread executes when an object in the design is readyfor processing by that thread. It will be appreciated of course that athread may have to wait for available processing resources (e.g.,computer cycle time) before it actually can begin to execute. When agiven thread completes processing of one object it proceeds to processanother object if another object is ready to be processed by it. Forinstance, for the flatten thread, a variant object is ready forprocessing when all data input nodes have data sets propagated to them.If no other object is ready for processing by the given thread, then thethread remains idle until the processing by one or more other threadsmakes another object ready for processing by that given thread. Forinstance, the propagate data sets thread may propagate data set types tothe input nodes of variant object. The flatten process will note thischange in the design, will emerge from the idle state and flatten thevariant object.

There is an inherent advantage to this form of synthesis. Specificallythe synthesis of one object in a design more naturally can be madedependent upon the synthesis of another object in the design. Anadvantage of this dependency is manifested in the creation ofpolymorphic objects described in other sections of this disclosure.

Contrast conventional compiler processing flow in which tokens areprocessed in a one-dimensional fashion. Basically, in languages such asC, Verilog and VHDL the next token to be processed is defined as thenext token in a function descriptor. These languages have specialconstructs, such as “Concurrent” in Verilog and “Parallel” in VHDL, toachieve parallel processing. By comparison, parallel dependencies amongobjects during a synthesis process are more naturally realized through aparallel synthesis process in accordance with a present embodiment ofthe invention.

The Axiom System and Basic Operators of High-Level Diagram BehaviorDescription Language

The synthesis process and the high-level diagram behavior descriptionlanguage of a present embodiment of the invention are founded upon anovel set of fundamental principles that we refer to herein as The AxiomSystem. An axiom is a self-evident or universally recognized truth. TheAxiom System described in this disclosure is new, and therefore, notuniversally recognized. However, it is believed to be self-evident.Significantly, The Axiom System serves as a foundation for an importantnew Postulate concerning the equivalency of the behaviors of differentdesign objects.

This section introduces the operators that comprise The Axiom System andseveral special operators developed for use with the high-level diagrambehavior description language.

This section also introduces the new Postulate regarding equivalency.Finally, this section places The Axiom System and the Postulate intoperspective by contrasting prior processes for creating a behavioraldesign for a system.

Axiom System

FIGS. H1-H8 provide pictorial representations of the operators of TheAxiom system. The Axiom System includes a basic information unit thatcan be operated on by two categories of operators. The basic informationunit is called an information atom (hereinafter an “atom”). The twocategories of Axiom System operators are location operators and stateoperators. The location operator category includes source object, sinkobject, transport object, and assignment object. The state operatorsinclude the AND, OR and INVERT logical functions.

According to the Axiom System, there exists an information atom 600illustrated in FIG. H1 that is defined by the following properties:location and state. Possible locations include nodes in a designbehavior created pursuant to The Axiom System. Possible states includelogical 0 and logical 1.

A source object 602 illustrated in FIG. H2 includes an output node 604.According to The Axiom System, a source object 602 can serve as a sourceof information atoms 600. An information atom 600 can have as itslocation the source node 604 of a source object 602.

A sink object 606 illustrated in FIG. H3 includes an input node 608.According to The Axiom System, a sink object 606 can serve as a sink forinformation atoms 600. An information atom 600 can have as its locationthe sink node 608 of a sink object 606.

A transport object 610 illustrated in FIG. H4 includes an input node 612and an output node 614. According to The Axiom System, the transportobject 610 can change the location property of an information atom. 600.An atom can have its location as the input node 612 or the output node614 of the transport object 610. The operation of the transport object610 is to transport information atoms 600 from the input node 612 to theoutput node 614. While the transport object 610 in FIG. H4 is shown withonly one output node 614, a transport object can have multiple outputnodes consistent with The Axiom System. The operation of a multi-outputnode transport object is to change the location property of aninformation atom from the input node to each and every output node.Thus, a multi-node transport object provides a branching operation.

An assignment object 616 is illustrated in FIG. H5. According to TheAxiom System, the assignment object 616 can assign a location to aninformation atom 600. (The assignment operator 616 is analogous tomemory storage medium in a computer system.)

A logical AND operator illustrated in FIG. H6 performs a logical ANDoperation on constant values. Specifically, it operates on the stateproperty of information atoms. For instance, providing two atoms withlogical states 1 and 0 respectively to the two inputs of the ANDoperator will result in an atom with logical 0 state on its output.

A logical OR operator illustrated in FIG. H7 performs a logical ORoperation on constant values. Specifically, it operates on the stateproperty of information atoms. For instance, providing two atoms withlogical states 1 and 0 respectively to the two inputs of the OR operatorwill result in an atom with logical 1 state on its output.

A logical INVERT operator illustrated in FIG. H8 performs a logicalINVERT operation on constant values. Specifically, it operates on thestate property of information atom. For instance, providing an atom withlogical 1 state to the input of the INVERT operator will result in aatom with logical 0 state on its output.

Thus, FIGS. H6-H8 illustrate the basic state operations selected for TheAxiom System. It will be appreciated that different state operators suchas combinations of the NOR or NAND logical functions, for example, couldhave been selected consistent with the invention.

Language Operators

FIGS. 11-15 provide pictorial representations of some special basicoperators of the language. These include data set type operators, acompiler directive operator, composite objects and a junction operator.More specifically, the data set type exposer illustrated in FIG. 11 andthe data set type collector illustrated in FIG. 12 are data set typeoperators. The variant selector illustrated in FIG. 13 is a compilerdirective operator. The composite object illustrated in FIG. 14 operatesto represent a hierarchy of logically equivalent behaviors. Thetransport junction object of FIG. 15 is a graphic object that operatesto display multiple output nodes from a transport object. Each of theobjects in FIGS. 11-15 is explained explicitly or through examples inother sections of this disclosure.

The Axiom System supports the following Postulate concerning theequivalency of behaviors in a system.

Postulate

Behavior A is equivalent to Behavior B so that Behavior B can besubstituted into the system to replace of Behavior A if,

-   -   Behavior A is logically equivalent to Behavior B; and    -   Data Set of Behavior A is equal to the Data Set of Behavior B;        and    -   Information Rate of Behavior A is less than or equal to the        Information Rate of Behavior B; and    -   Action Latency of Behavior A is greater than or equal to Action        Latency of Behavior B.

Logical equivalence means that for any given set or pattern of inputinformation atoms, two behaviors will produce the same set or pattern ofoutput information atoms. In a presently preferred embodiment of theinvention, logical equivalence of behavior objects is signified throughnaming. Thus, in a current embodiment, objects that include the samename are considered as logically equivalent. For instance, an objectwith the name “Add” is considered to be logically equivalent to anotherobject that includes the name “Add”. There may be multiple types oflogically equivalent “Add” objects in an object library available to asystem. For example, an object library might include instances of thefollowing logically equivalent Add objects, Parallel Add object, SerialAdd object, Saturating Add object, Floating Point Add object, ComplexNumbers Add object and Vector Data Set Add object.

A Data Set signifies a format of information atoms. In a currentimplementation of the invention, a Data Set signifies a collection ofinformation atoms organized as a recursive hierarchy of other data setswith the default data set being a single atom (1-bit). The Data Set canbe associated with a node of an object. A Data Set associated with aninput node of an object signifies the type of data set that can flowinto the node.

Information Rate is measured in atoms per unit of time (e.g., atoms persecond). The Information Rate associated with an input node of an objectsignifies the rate at which atoms can flow through (for a transportobject) or be processed by (for a transformative object that alters anatom's state e.g., an Add object, Subtract object or Multiply object).The Information Rate associated with an output node of an objectsignifies the rate at which atoms can be supplied by the node to anotherobject (i.e., a transport object) connected to the output node.

Action Latency is the time between the arrival of an atom at an inputnode of an object and the time of arrival of a resulting atom at anoutput node of the object. It is the transit time through a transportobject and the transformation time in a transformative object. In acurrent embodiment of the invention the Action Latency of an object isderived from the following relationship.AL=CL+RL

AL represents Action Latency. CL represents Compute Latency. RLrepresents Reaction Latency. Compute Latency is the time required toperform a transit (transport object) or a transformation (transformativeobject). Action Latency is the setup time for an object. For instance,AL or setup time may be significant in time division multiplexingapplications.

New Perspectives on Behavioral Synthesis Through the Axiom System

The Axiom System permits the description of system behavior independentof time. That is, time need not be a factor or element of a descriptionof system behavior. As explained below, a consequence of the ability todescribe system behavior independently of time is that symbolsubstitution can be used to synthesize a design (e.g., netlist) from abehavioral description (e.g., diagrammatic representation of desiredsystem behavior). That is, a symbol may inserted in a design torepresent behavior. During synthesis, one or more other equivalentobjects may be substituted into the design in place of the symbol. Thus,symbolic substitution can be used as a mechanism for synthesis.

The Postulate permits parameterization of synthesis by symbolicsubstitution. For instance, Information Rate and Action Latency can beused as parameters used to decide which equivalent object to substitutein place of a symbol in a design. That is, synthesis by symbolicsubstitution can be made to select among multiple possible alternativesubstitutions for a symbolically represented behavior in a design basedupon one or more parameters such as Information Rate and Action Latency.Since Information Rate and Action Latency are defined in terms of time,selective symbolic synthesis can be parameterized to depend on time.Thus, parameterized selective symbolic substitution can be used as amechanism for synthesis.

An implication of the ability to conduct synthesis through selectivesymbolic substitution is the ability to define behaviors in terms ofpolymorphic objects. A polymorphic object is one that can be resolvedinto any of multiple objects during the synthesis process. Animplication of the ability conduct synthesis through parameterizedselective symbolic substitution is the ability to condition theresolution of a polymorphic object upon parameter(s) external to thebehavior of the object. A polymorphic object that is associated with acondition imposed on its resolution during synthesis is referred toherein as a parameterized polymorphic object. An implication of theability to create designs with parameterized polymorphic objects is theability to create a synthesizeable description of desired designbehavior that can be resolved differently during synthesis dependingupon the particular values assigned or derived during synthesis for theparameters associated with polymorphic objects in the behavioraldescription (e.g., external to the diagrammatic description of designbehavior).

A Fundamental Change in System Design

It is believed that The Axiom System presents an opportunity for afundamental change in system design techniques. An earlier fundamentalshift in system design techniques was initiated by Alan Turing when hesolved the inverter problem through the introduction of state atdiscrete times. The inverter problem is best understood throughreference to the schematic diagram of FIG. K1 which shows an inverterwith its input and output connected together by electrical conductors(not transport objects). The logical state of the inverter is undefinedsince its input is connected to its output. Specifically, according tothe rules of boolean logic, an inverter cannot be both in a logical 0state and a logical 1 state simultaneously. Thus, the inverter problempresented a case in which the rules of the boolean logic axiom systemfailed to describe circuit behavior.

Turing's solution to the inverter problem is best illustrated in theschematic diagram of FIG. K2 which shows an inverter with its outputconnected by an electrical conductor to an input to a state element andwith its input connected to an output of a state element by anelectrical conductor. Turing introduced the notion of state at discretetimes. At one instant of time, the state of the logical state element islogical 1, and it outputs a logical 1 to the input of the inverter whichoutputs a logical 0 value. In a next instant of time, the logical 0output by the inverter, in the prior time instant, has changed the stateof the state element to logical 0. In this next instant in time, thestate element outputs a logical 0 to the input of the inverter whichoutputs a logical 1. Turing's solution is to represent a system usingstate in discrete time.

From a behavioral design perspective, a drawback of a behavioraldescription of a design in terms of state in discrete time is thatselective symbolic substitution is not a feasible synthesis mechanism.Basically, the presence in a behavioral description of state in discretetime makes it infeasible to use symbol substitution to synthesize adesign from such a description.

The Axiom System enables a new process for describing system behavior.This new process overcomes the problems described in the precedingparagraphs by using location instead of state in discrete time in therepresentation of system behavior. The drawing of FIG. K3 shows abehavioral object 700 which includes an inverter object 702 with aninput node 704 and an output node 706. The object 700 includes atransport object 708 with an input node 710 and an output node 712. Thedrawing of FIG. K3 diagrammatically represents the behavior of object700. The following table also represents the behavior of object 700which involves changing the state of an atom as it is propagates throughthe object 700. In studying the table, assume that a trigger eventcauses incremental flow of the atom from one node to the next insideobject 700. The table shows a sequence of location and state of the atomwithin the object 700 for a sequence of trigger events from T1 to T7.TABLE Inverter Problem Solution With State and Location Trigger EventLocation State T1 Node 712 S1 T2 Node 704 S1 T3 Node 706 S2 T4 Node 710S2 T5 Node 712 S2 T6 Node 704 S2 T7 Node 706 S1

At no point in the behavior described diagrammatically in FIG. K3 anddescribed in table format above is the state or location of the atomundefined. Thus, The Axiom System provides a new process for describingthe behavior of a systemic a manner that is independent of state indiscrete time.

However, from the Postulate it will be appreciated that The Axiom Systemenables the creation of parameterized behavioral descriptions of adesign. The parameters themselves can be time dependent. For instance, apresent embodiment of the invention employs parameterized polymorphicobjects using as parameters Information Rate and Information RatePattern. Thus, a synthesis process in accordance with the invention canemploy selective symbol substitution that is driven by time-dependentparameters. Therefore, the present invention provides a fundamentallynew mechanism for the synthesis of a system design from a behavioraldescription of the system.

“Variant”

The term “variant” is used in this disclosure in reference to data settype. An object with variant data set type on a node is a data setpolymorphic object. A variant data set is abstract. An object that isdata set polymorphic can be resolved into more than one form of theobject depending on the type(s) of data set(s) propagated to it inputnodes. A variant data set type object need not be continuouslyresolvable. There may be multiple possible discrete resolutions of theobject. The particular resolution in any given case depends upon thenature of the explicit data set(s) propagated to the input node(s) ofthe object during the synthesis process. The term variant as used hereinis not intended to be synonymous with the variant class in the Pascallanguage.

Node Structure and the Object Hierarchy

This section describes the object class structure used to constructbehavior objects in a current implementation of the invention. Thereader should realize that although we speak in object orientedprogramming terms in this section of the disclosure, the use of the termobject in this section should not infer that the use of the term objectin other sections, e.g., parameterized polymorphic behavior objects, isintended to limit behavior objects to an object oriented programmingimplementation. Having made this disclaimer as to interpretation of theterm object, this section apprises the reader that an object orientedprogramming approach in fact has been used to implement behavior objectsin a presently preferred embodiment of the invention. Class I² ADLObject (I² ADL stands for Implementation Independent AlgorithmDescription Language) { Name Inputs (list of input nodes) Outputs (listof output nodes) Attributes (list of strings) Behavior (list of I² ADLObjects) } Class Node Object { Information Rate* (pointer to classInformation Rate object) Data Set* (pointer to class Data Set object)Connected to (pointers to other nodes) Owner (pointer to I² ADLobject)Attributes } Class Data Set Object { Elements (list of data sets in thedata set in order of precedence) } Class Information Rate { Float IRFloat RL Float CL INT IRP (Information Rate Pattern) String IRP function(for complex patterns such as FFT or DCT) }

Note that each I²ADL object comprises nodes with “connected to”information. This object class structure forms permits the resolution ofa diagrammatic representation of desired behavior into a netlistcomprising a network of low-level objects. In a preferred embodiment,the low-level objects are atomic objects. The composite objects of thediagrammatic representation are synthesized into atomic objectsinterconnected through the “connected to” node structures. As aconsequence of this object class structure, changes in higher levelcomposite objects leave the basic underlying object class structureintact, ensuring resolution during the synthesis process from atop-level behavioral description to a network of low-level objects.

Select Object

The select object is used to select among alternative implementations ofa behavior in the course of the selective synthesis process. The SelectObject is not a behavior per se in that it is used to direct theselective synthesis process, but it is not resolved into an atomicbehavior that can be implemented in a design. Basically, it is abranching mechanism. A select object ordinarily operates in conjunctionwith a control process that also is operative during the selectivesynthesis process. The control process may be implemented through acontrol object that is a composite object that is responsive to one ormore parameter values. The composite object causes the select object toselect from among multiple possible implementations of a behavior. Inessence, the control object uses the one or more parameters to resolve acondition upon which the select object selects among multiple possibleimplementations of a behavior. Of course, the nature and constructionand implementation of the control object varies depending upon thenature of the condition controlling the selection by the select object.Thus, in a sense, the select object plus an associated control objectcan implement a conditional branching during the synthesis process.

Essentially, the select object operates as a compiler instruction. Itserves to select from among multiple possible implementations of abehavior. However, in a present embodiment of the invention, it does notitself reference behavior that is actually included within a synthesizedresult. Moreover, in a current embodiment of the invention, a controlobject that controls the selection or branching by a select objectessentially operates as one or more instructions for resolving acondition on which a conditional branch is to occur. As such, thecontrol object ordinarily is not included as part of a synthesizedresult. Rather, such control object typically is removed from a designdatabase after it has served its function of controlling a selection bythe select object during the synthesis process.

The select object is associated with a conditional process (or analgorithm). During the selective synthesis process, a conditionalprocess associated with a given select object is invoked, and a controlobject associated with that given select object resolves the conditionof the conditional process. The associated process effects a selectionof behaviors based upon the resolution of the condition. As a result ofthe selection of behavior, a design database that includes the selectobject is modified so as to effect a connection between an input node ofthe select object and an output node of the select object. As explainedbelow, by effecting such a connection, the select object can selectbetween multiple implementations of a behavior.

Referring to the illustrative drawings of FIG. A1, there is shown adiagram representing an example of a select object. A block 100 thatincludes a data input node 102, a select input node 104 and an outputnode 106, represents the select object. The block 100 can be insertedinto a design diagram to implement a branch during a synthesis process.During the synthesis process, the block 100 causes the synthesis process(compiler) to invoke a conditional process associated with the blockthat causes the synthesis process to process a branch operation.

There are two possible results of a branch implemented by a conditionalprocess associated with the select object 100 of FIG. A1. The first isthat the data input node 102 will become interconnected with the outputnode 106. The second is that the data input node 102 will becomeunconnected to the output node 106. The one result or the other dependsupon the value of a signal provided on the select input node 104. Forinstance, referring to FIG. A2, if a first value, or perhaps a firstrange of values, is provided on input node 104, then the data input node102 will become connected with the data output node 106. In a presentembodiment of the invention, the data input node and the data outputnode become connected with a transport object 108. Referring to FIG. A3,if a second value, or perhaps a second range of values, is provided onthe select input node 104 then the data input node 102 will becomeunconnected with the data output node 106.

In a present embodiment of the invention, a given select object is anatomic object. Thus, it does not reference other lower level objects.However, as explained above, it does have a process (or algorithm)associated with it. In the example of FIGS. A1-A3, a branching algorithmcan be represented in is straightforward terms as follows.

If value on input select node=1, then connect the data input node to thedata output node;

If value on input select node=0, then do not connect the data input nodeto the data output node.

A control process implemented by a composite object (not shown) in thedesign database, for example, can be run during the synthesis process inorder to derive the value on the select input node 104. It will beappreciated that the composite object that effects the control processis not a part of the select object itself.

Referring to the illustrative drawing of FIG. B1, there is shown anexample of another implementation of a select object. A block 120 thatincludes a data input node 122, data input node 124, select input node126 and an output node 128, represents the select object. The block 120can be inserted into a design diagram and a corresponding designdatabase to implement a branch during a synthesis process. During thesynthesis process, the block 100 causes the synthesis process (compiler)to invoke a conditional process associated with the block that causesthe synthesis process to process a branch operation.

There are two possible results of a branch implemented by a conditionalprocess associated with the select object 120 of FIG. B1. The first isthat the data input node 122 will become connected with the output node128, and data input node 124 will not be connected. The second is thatthe data input node 124 will become connected to the output node 128,and data input node 122 will not be connected. The one result or theother depends upon the value of a signal provided on the select inputnode 126. For instance, referring to FIG. B2, if a first value, orperhaps a first range of values, is provided on select input node 126,then the data input node 122 will become connected with the data outputnode 128, and the data input node 124 will not be connected. In apresent embodiment of the invention, the data input node 122 and thedata output node 128 become connected with a transport object 130.Referring to FIG. B3, if a second value, or perhaps a second range ofvalues, is provided on the select input node 126 then the data inputnode 124 will become connected with the data output node 128, and datainput node 122 will not be connected. In a present embodiment of theinvention, the data input node 124 and the data output node 128 becomeconnected with a transport object 132.

In the example of FIGS. B1-B3, a branching algorithm associated withselect object 120 can be represented in is straightforward terms asfollows.

If value on input select node=1, then connect data input node 122 to thedata output node 128 and do not connect data input node 124;

If value on input select node=0, then connect data input node 124 to thedata output node 128 and do not connect data input node 122.

A control process can be implemented by another object in the designdatabase to derive the value on input select node 126.

Referring to the illustrative drawing of FIG. C1, there is shown anexample of another implementation of a select object. The select objectof FIG. C1 includes four data input nodes 142, 144, 146 and 148, a dataselect node 150 and a data output node 152. The select object 140 ofFIG. C1 references the library object illustrated in FIG. C2 which is acomposite object comprising three atomic select objects 154, 156 and 158of the general type shown in FIGS. B1-B3.

Referring to FIG. C2, the data inputs of a first constituent selectobject 154 are respectively connected by transports 160 and 162 to datainput node 142. The data inputs of the second constituent select object156 are respectively connected by transports 164 and 166 to data inputnodes 146 and 148. The data inputs of the third constituent selectobject are respectively connected by transports 168 and 170 to therespective data output nodes of the respective first and secondconstituent select objects 154 and 156. The data output node of thethird constituent select object is connected by transport 172 to dataoutput node 152.

A data set exposer 174 includes a data input node 176 and two dataoutput nodes 178 and 180. (The structure and operation of a data setexposer in a present embodiment of the invention are described below.)The data set exposer input node is connected by a transport 182 toselect input node 150. One output node of the data set exposer 174 isconnected by transport 184 with the select input nodes of both the firstand the second constituent select objects 154 and 156. The other outputnode of the data set exposer 174 is connected by transport 186 to theselect node of the third constituent select object 158.

The select object 140 can be inserted into a design diagram and acorresponding design database to implement a branch during a synthesisprocess. During the synthesis process, the block 140 causes thesynthesis process (compiler) to invoke a conditional process associatedwith the block 140 that causes the synthesis process to process a branchoperation. More specifically, a conditional process associated withselect object 140 invokes for each of the three constituent selectobjects 154, 156 and 158, a conditional process of the general typedescribed with reference to FIGS. B1-B3. The result will be amodification of the design database in which the select object 140 isconnected to include the connection of only one of the data four inputnodes 142, 144, 146 and 148 to the data output node 152. The other threedata input nodes will not be connected. For example, referring to theillustrative drawing of FIG. C3, there is shown the connection of datainput node 146 to data output node 152 through the addition oftransports 188 and 190 to the design database. More specifically, inthis example, data input node 146 is connected by the concatenation oftransports 164, 188, 170, 190 and 172 to node 152. Moreover, it will beunderstood from the other sections of this disclosure that the ultimateresult of the overall synthesis process will be the replacement of themultiple transport objects and nodes in the transport path between thedata input node 146 and the data output node 152 by a single transportobject (not shown). The processes that cooperate to reach this ultimateresult are not a part of the select object per se and are explained inother portions of this disclosure. Furthermore, it will be appreciatedthat FIG. C3 shows just one of four possible outcomes of a conditionalprocess associated with select object 140. One skilled in the art willappreciate that, depending on the value applied to select input node150, any one of data input nodes 142, 144, 146 and 148 could beconnected to data output node 152 in a similar manner by appropriateaddition of transports to the design database.

A select input value applied to select input node 150 determines how thecondition process will be resolved for each of the three constituentselect objects 154, 156 and 158. A control process implemented as partof the synthesis process using another composite object (not shown) inthe design database can be used to derive the value applied to selectinput node 150. In the example of FIGS. C1-C3, a branching algorithmassociated with select object 140 can be represented in isstraightforward terms as follows.

If value on input select node=00, then connect data input node 142 tothe data output node 152 and do not connect data input nodes 144, 146 or148;

If value on input select node=01, then connect data input node 144 tothe data output node 152 and do not connect data input nodes 142, 146 or148;

If value on input select node=10, then connect data input node 146 tothe data output node 152 and do not connect data input nodes 142, 144,or 148;

If value on input select node=11, then connect data input node 148 tothe data output node 152 and do not connect data input nodes 142, 144 or146.

In the above branching algorithm, the least significant bit on selectinput 150 controls the first and second constituent select objects 154and 156. The most significant bit on select input node 150 controls thethird constituent select object 158. A control process can beimplemented by another object in the design database to derive the valueon input select node 150.

As explained in other sections of this disclosure, the select valueapplied to select node 104 of FIGS. A1-A3 or to select node 126 of FIGS.B1-B3 or to select node 150 of FIGS. C1-C3 can be provided or derivedbased upon any number of parameters. These parameters might include oneor more of the following in combination or individually: data set type,information rate, data set pattern, action latency, compute latency,etc. The object in the design diagram and in the design database thatdrives the control process uses the appropriate parameter(s) to arriveat a select input value.

In a present embodiment of the invention, the data input nodes and theoutput node of a select object are of a variant type. That is, the datainput and data output nodes could be connected with other nodes of anytype. This variant typing of the data input and output nodes makes theselect object extremely versatile. A select object with more than onedata input node can have transports with different data set typesconnected to different ones of its multiple data input nodes. A selectobject can be connected into a design diagram and a corresponding designdatabase and can be used to effect conditional branching among differentbehaviors that process different types of data sets. However,ordinarily, the select input node will have a constant type value.Although the exact value of the constant provided on the select inputnode may be derived by another control object as explained above.

The basic select objects described above can serve as building blocks tocreate synthesis control structures for selective synthesis of behaviorsin a design. In that regard, it will be appreciated that select objectslike those of FIGS. A1-A3, B1-B3 and C1-C3 are merely representative.Select objects can be concatenated in many different combinations inorder to implement more complex conditional branching. One implicationof the ability to achieve conditional branching as part of a designsynthesis process is the ability to implement selective synthesis inwhich behavior included in a design depends upon the outcome ofconditional branching during the synthesis process.

Data Set Exposer and Data Set Collector Objects

In a present embodiment of the invention, variant objects decouple datasets from design topology. That is, a design topology can be constructedwith variant objects without specifying how the topology will beimplemented for any given data set. Thus, a design constructed withvariant objects is type independent. Specifically, such design is dataset type independent.

A data set exposer object is an object that symbolically referencesalgorithms or processes for breaking down a data set into itsconstituents. A data set collector object symbolically referencesalgorithms or processes for building up a data set from its constituentparts. The illustrative drawings of FIG. G1 represent several types ofdata set exposers and corresponding data set collectors according to apresently preferred embodiment of the invention. A currentimplementation of the invention can implement a design with any one ormore of several different types of default data sets. The data setsinclude bit (1-bit), Dbit (2-bits), Nibble (4-bits), Byte (8-bits), Word(16-bits), Dword (32-bits) and Qword (64-bits). A respective explicitdata set exposer object and a corresponding respective explicit data setcollector object is provided for respective corresponding types of datasets. FIG. G1, illustrates data sets and corresponding explicit data setexposers and explicit data set collectors.

It will be appreciated that, although only a few different types of datasets are described herein, any type of data set can be defined (e.g.,floating point type or integer type). A data set exposure and a data setcollector can be constructed for any such defined data set. That is,respective algorithms for the respective exposer and collector objectscan be respectively created for any such defined data sets.

The data set exposers and data set collectors of FIG. G1 are referred toherein as having explicit data set types because the data sets theyoperate on are explicitly defined. A Dbit type exposer object breaksdown a Dbit type data set into two Bit type data sets. A correspondingDbit type collector object builds a Dbit type data set from two Bit typedata sets. A Nibble type exposer object breaks down a Nibble type dataset into two Dbit type data sets. A corresponding Nibble type collectorobject builds a Nibble type data set from two Dbit type data sets. AByte type exposer object breaks down a Byte type data set into twoNibble type data sets. A corresponding Byte type collector object buildsa Byte type data set from two Nibble type data sets. A Word type exposerobject breaks down a Word type data set into two Byte type data sets. Acorresponding Word type collector object builds a Word type data setfrom two Byte type data sets. A Dword type exposer object breaks down aDword type data set into two Word type data sets. A corresponding Dwordtype collector object builds a Dword type data set from two Word typedata sets. A Qword type exposer object breaks down a Qword type data setinto two Dword type data sets. A corresponding Qword type collectorobject builds a Qword type data set from two Dword type data sets.

A presently preferred embodiment of the invention also includes varianttype data set exposer objects and variant type data set collectorobjects. They are referred to as variant type because they do notoperate on any particular data set. Rather, in a current embodiment, avariant type data set exposer object references the above explicit dataset type exposer objects. Similarly, a variant type data set collectorobject references the above explicit data set type collector objects.The illustrative drawing of FIG. G2 shows a portion of an object libraryin which a variant type data set exposer object references each of theexplicit data set type exposer objects. Similarly, The illustrativedrawing of FIG. G3 shows a portion of an object library in which avariant type data set collector object references each of the explicitdata set type collector objects.

A variant data set exposer built into a design is resolved during asynthesis process in accordance when a data set is propagated to theinput node of such exposer object has a data set propagated to it, theflatten algorithm references the portion of the object libraryillustrated in FIG. G2. The flatten algorithm searches for an explicitdata set type exposer object with an explicit data set type on its inputnode that matches the data set type that has been propagated to thevariant type data set exposer during the propagate data sets process. Ifit finds a match, it inserts the matching explicit data set type exposerobject into the design in place of the variant data set type exposerobject.

Conversely, a variant data set collector built into a design is resolvedduring a synthesis process in accordance when data sets are propagatedto the two input nodes of such a variant data set type collector.Basically, when the input nodes of a variant type data set collectorobject has a data set propagated to it, the flatten algorithm referencesthe portion of the object library illustrated in FIG. G3. The flattenalgorithm searches for an explicit data set type collector object withan explicit data set type on its two input nodes that matches the dataset types that have been propagated to the variant type data setcollector during the propagate data sets process. If it finds a match,it inserts the matching explicit data set type collector object into thedesign in place of the variant data set type collector object.

The role of an explicit data set exposer object inserted into a designis to reference a process or algorithm used during the synthesis processto break down a data set into its constituent data sets. For instance,when a Dbit type data set exposer object is inserted into a design itcauses the synthesis process to reference an algorithm which breaks downthe Dbit data set into two separate bit type data sets. One of the twobit type data sets is provided as an output on one of the Dbit type dataset exposer's two output nodes. The other of the two bit type data setsis provided as an output on the other of the Dbit type data setexposer's two output nodes. Continuing with this example, with Bit typedata sets defined on the output nodes of the Dbit data set exposerobject, the propagate data sets process then can propagate the two Bittype data sets provided on the two output nodes to transport objectsconnected to those nodes.

The role of an explicit type data set collector object inserted into adesign is analogous to that of an explicit type data set exposer object.An explicit type data set collector object references a process oralgorithm used during the synthesis process to build up a data set intofrom its constituent data sets. For instance, when a Dbit type data setcollector object is inserted into a design it causes the synthesisprocess to reference an algorithm which builds up the Dbit data set fromtwo separate bit type data sets that have been propagated to its twoinput nodes. The Dbit type data set is provided as an output on the Dbittype data set collector's output node. Continuing with this example,with a Dbit type data set defined on the output node of the Dbit dataset collector object, the propagate data sets process then can propagatethe Dbit type data set provided on the output node to transport objectsconnected to that node.

It will be appreciated that the invention may be practiced withoutactually inserting an explicit exposer object or an explicit collectorobject into a design to replace a variant object. Rather, a resolutionof a variant data set exposer object may involve a selection of a dataset break-down process or algorithm that can be used to direct the dataset propagation process. Similarly, resolution of a variant data setcollector object may involve selection of a data set build-up process oralgorithm that can be used to direct the data set propagation process.In essence, through respective break-down and build-up algorithms, arespective variant type data set exposer object and a respective varianttype data set collector object direct the synthesis process in carryingout a data set type dependent propagation of data sets.

Type Dependent Instructions—Variant Data Set Type Exposer Object andVariant Data Set Type Collector Object

From one perspective, a variant data set exposer object and the variantdata set collector object are inserted into a design so as to cause asynthesis process in accordance with a present embodiment of theinvention to reference one or more algorithms that direct the break-downand build-up of data sets. Ordinarily, they are inserted into a designas component objects of a composeter object. For instance, see thevariant data set exposer object 510 and the variant data set collector512 object of the variant invert object 502 of FIG. F3.

From another perspective, the variant data set exposer object and thevariant data set collector object can serve to direct a synthesisprocess in the resolution of abstract type. A variant data set typebehavior object has an abstract data set type. Such an object can becharacterized as a data set type polymorphic behavior object. Itsbehavior exact varies according to data set type. For instance, each ofthe top-level invert object 500 and the variant invert object 502 ofFIGS. F1-F3 has abstract data set type and is data set type polymorphic.Recall that during a synthesis process in accordance with a presentlypreferred embodiment of the invention, a variant data set type behaviorobject in a design is resolved into one or more explicit data set typebehavior objects. See for example the discussion with reference to FIGS.F1-F8. In essence, a variant data set type exposer object directs thesynthesis process during the resolution of a variant data set typebehavior object into one or more explicit data set type behaviorobjects. In effect, a variant data set type exposer object serves as asynthesis (compiler) instruction that guides a synthesis process in theresolution of an abstract data set type into explicit data set typeobject.

Considering both of these perspectives, a variant data set type exposerobject can be viewed as a synthesis (compiler) instruction that is builtinto (or at least associated with) a variant type data set behaviorobject (e.g., the invert behavior object 502 of FIG. F3) to direct theflatten and propagate data sets processes in the resolution of a variantdata set type behavior object into one or more explicit data set typebehavior objects. Moreover a variant data set type exposer object can beviewed as a data set type dependent synthesis (compiler) instruction. Inthat regard, it is an adaptive instruction. Specifically, the nature ofthe instruction depends upon the nature of the data set propagated toit. Thus, the variant data set type exposer object in essence is typedependent (compiler) instruction for resolving variant data set typebehavior objects based upon data set type. Briefly stated, such variantexposer object is an instruction used to resolve data set type of avariant behavior object in accordance with data set type propagated tothe variant exposer object.

To appreciate this perspective, consider that the flatten and propagatedata sets processes iteratively resolve a variant data set type behaviorobject by incrementally breaking down a data set propagated to suchobject into its constituent data sets. One or more new instances of suchvariant data set type behavior object is inserted into the design inplace of the instance of such behavior object that is being resolved.One or more constituent data set(s) is (are) propagated to each newlyinserted instance of the behavior object that is being resolved. Thisiterative process continues until the inserted instances of the behaviorobject that are being resolved together with the constituent data setspropagated to their input nodes each match a behavior object in anobject library. During this iterative resolution process it is thevariant data set type exposer object built into the variant data settype behavior object that is being resolved in effect drives theincremental and iterative break-down of a data set into constituents.See for example FIGS. F5-F8. Thus, the variant data set type exposerobject serves as an instruction that is built in to a variant data settype behavior object.

Moreover, during each successive iteration, the variant type data setexposer object causes the propagate data sets process to propagate adifferent constituent data set to each newly instantiated instance ofthe variant behavior object that is being resolved. For instance, duringone iteration, a nibble data set (4-bit) might be broken down into twoDbit type data sets (2-bits each). During a next iteration, the two Dbittype data sets might be broken down into four bit type data sets (1-biteach). See for example FIGS. F5-F8. Thus, the variant data set typeexposer object serves as a data set type dependent instruction.

One important role of a variant data set type collector object is toensure that the process of resolving one variant data set typebehavioral object in a design does not change the pattern of transportobjects that propagate data sets from the perspective of other objectsconnected downstream in a design. More specifically, the process ofresolving data set polymorphic behavior objects (such as the variantinvert object 502 of FIG. F3) using a variant data set type data setexposer object may create a network of newly instantiated transportobjects not originally present in the original design. In order toensure that these new transports do not alter the connections todownstream objects in a design, one or more variant data set typecollector objects are inserted into a design so that the number ofoutput nodes after resolution of a variant data set type behavior objectis the same as the number of nodes before resolution, regardless of howmany instances of that (or another) behavior object are inserted intothe design during the resolution process.

Consider that the variant data set type exposer object and the variantdata set type collector object can be thought of as templates. They areakin to type dependent objects. Moreover, they serve as synthesis(compiler) instructions. That is, they are type dependent instructions.Since type that becomes associated with a given variant exposer objector with a given variant collector object depends upon the data set typepropagated to it at synthesis time, they are both adaptive instructions.

Thus, in essences, the variant data set type collector object alsoserves as a data set type dependent instruction. Specifically, it is aninstruction built in to a variant data set type object to direct thesynthesis process to instantiate a network of transport objects that areassociated with each other so that the number of output node connectionsfrom a variant data set type behavior object does not change due to theresolution of the object based upon propagated data set type. Theinstruction implemented through the variant data set type collectorobject is complementary to the instruction implemented through thevariant data set type exposer object. The result of the operation ofthese complementary instructions is the insertion into a design of anascending hierarchy of exposer objects and a complementary descendinghierarchy of collector objects. See FIG. F8 for example. The result ofthe complementary action of these two instructions is that a network oftransports inserted data set type resolution of one variant data settype behavior object does not affect the connections to other objects inthe design that are upstream or downstream from the resolved object.

Transport Object

A transport object serves as an operator in The Axiom System thatchanges the location property of information atoms from the location ofan input node of the transport object to locations of each output nodeof the transport object. In practice, in a synthesis process inaccordance with the invention, a transport object operates to change thelocation property of a data set from the location of an input node ofthe transport object to the locations of each output node of thetransport object. In a synthesis process of the present invention, atransport object initially has abstract or variant data set type when itis inserted into diagrammatic design. That is, it is not associated withany particular data set. However, the propagate data sets process willpropagate an explicit type data set to the input node of such anabstract data set type transport object the during the synthesisprocess. In response to of such propagation, the input node of thetransport object will copy the data set, and thereby be transformed tothe data set type, that has been propagated to it. The transport objectthen will copy the data set, and therefore the data set type, to theoutput node of the transport object.

In order to effect the above change in location property, the transportobject is associated with a process that copies a data set type on theinput node of an instance of the transport object to the output node ofthat instance of the transport object. When a synthesis thread reachesthe input node of an instance of a transport object, it references suchprocess and thereby causes the copying or propagation of data set typefrom the input node of the transport object instance to each of itsoutput nodes. An instance of a transport object may have multiple outputnodes.

By changing the location property of a data set and its correspondingdata set type, the transport object serves to define the flow of thesynthesis process. As explained above, there are several threads ofexecution that run concurrently during the synthesis process. Theresults of the operation of one thread on a given node or object cansubject that node or object to processing by yet another thread. Forinstance, a transport object, by propagating a data set from its inputnode to each of its output nodes, in effect, prompts or triggers thepropagate data sets process to propagate the data set to an input nodeof an object connected to the transport object. The propagation of thedata set to that node might, in turn, prompt or trigger the operation ofthe flatten process, which in turn, might prompt other threads ofexecution on other nodes.

Thus, a diagrammatic behavioral design can be assembled in which variantbehavior objects are connected by abstract transport objects. The use ofabstract transport objects permits the creation of a diagrammaticbehavioral description of a design that is data set independent. Theformats or data sets types of that flow through the diagram need not bedefined in the behavioral description because abstract transport objectscan propagate any data set type. However, in the course of the synthesisprocess, each abstract transport object will adopt or copy the data settype of the data set propagated to it. Thus, at the outset of thesynthesis process, an abstract transport object serves to help directthe flow of the threads of execution of the synthesis process. However,as each abstract transport object changes the location property of thedata set propagated to it, it is transformed into a transport objecthaving explicit data set type. A transport having explicit data settype, in essence, describes the connections that will be required in thefinal synthesized design. In other words, the explicit transport objectsserve to define the actual network of connections that will be requiredin the final synthesized design.

Cast Behavior Object

In a presently preferred embodiment of the invention, a cast behaviorobject is used to cast a given data set of one type to a data set ofanother type. By way of background, it is conventional to use a typeoperator to cast a type to a variable in other computer programminglanguages. Thus, strongly typed languages, such as the C programminglanguage typically employ manner of type casts. By way of furtherbackground, prior logic or behavioral synthesis tools ordinarilyrepresent the notion of transport of data or control information fromone object in a design to another object in a design in terms of vectorsand buses. Prior logic or behavioral synthesis tools typically do notrepresent the notion of transport of data and control in terms ofabstract transport objects as in a present embodiment of the invention.Thus, although casting a type to a variable is well known, casting typeto an abstract transport object is not known in prior logic orbehavioral synthesis tools.

The role of the cast behavior object can be better appreciated with abetter understanding of behavioral synthesis in accordance with apresent embodiment of the invention. A current embodiment of thesynthesis process employs abstract transport objects. That is, using thepresent synthesis process, a design may be constructed from libraryobjects that include transport objects that are not associated with anyparticular data set. In other words, such transport objects haveabstract type. Thus, a design may be created in which the notion oftransport of data and control from one object to the next is representedin terms of abstract transport objects rather than in terms of vectorsand buses.

An advantage of abstract transport objects is that a design can beconstructed independent of data set type. Nevertheless, at some point,in order to actually use the design to create or specify a usefulsystem, abstract transport objects (and other abstract behavior objects)in the design must have data set types cast to them. Thus, the use ofabstract transport objects in a synthesis process in accordance with thepresent invention creates a need for a mechanism to cast a data set typeto abstract transport objects. One mechanism for casting data set typesto abstract transport objects (and to other abstract behavior objects)is the data set propagation process described elsewhere in thisdisclosure. Another mechanism for casting data set types to abstracttransport objects is the cast behavior object described in the followingparagraphs of this section.

A potential problem that could arise with abstract transport objects ina design that relies upon data set propagation to cast data set types toabstract transport objects is that the resulting casting of abstracttransports could result in an inoperative design. For instance, considera hypothetical add behavior object in a design that has two data inputnodes connected to two different abstract transport objects. Suppose,for example, that during data set propagation, a byte type data set(eight bits wide) was cast to the transport object connected to one ofthe input nodes, and a word type data set (sixteen bits wide) was castto the transport object connected to the other input node. How is theadd object to perform an add behavior so as to arise at a sum value byadding a value represented by a byte data set to another valuerepresented by a word data set? A problem would arise because these arenot matching data sets.

In order to avoid this specific problem, a cast behavior object can beinserted into a design so as to cast the type of one abstract transportobject to a type that matches that of another transport object. In asense, a cast behavior object would function as a “symmetricalizer”. Itwould ensure that two (or more) transport objects were cast to the samedata set type. More generally, as explained below, a cast behaviorobject can be inserted into a design to cast an abstract transportbehavior object to any desired type. In the above hypothetical example,the byte data set could be cast to a word data set, and a transportobject that otherwise would have been cast to byte data set type, couldbe cast to word data set type. Thus, the transports on both input nodesof the add object would be word type and would match. The input nodeswould have symmetrical inputs. The cast behavior object would have beenused to “symmetricalize” the data set types on the input nodes. Thus, acast behavior object can be used to ensure that casting of type, tobehavior objects, during synthesis, through data set propagation, doesnot result in an inoperative design.

Example of Resolution of a Cast Behavior Object

Referring to the illustrative drawing of FIG. E1A, there is shown arepresentation of a top-level cast behavior object 490. The cast objectincludes a data set type input node 492, a data set input node 494 and adata set type output node 496. The overall behavior of a cast behaviorobject 490 is to cast a data set propagated to node 494 to the type ofdata set indicated on node 492. The overall behavior also includesproviding on node 496, as an output, the data set on node 494 cast tothe type on node 492. The type on node 492 may be obtained from a fixedvalue or it may determined based upon a data set type propagated withinthe design during synthesis process. That is, it may vary depending uponthe nature of the data set type provided to it.

Referring to the illustrative drawing of FIG. E1B, there is shown aportion of an object library that pertains to cast behavior. Thetop-level cast object 490 references a next-level cast object 400. Boththe cast objects 490, 400 are variant type. The top-level cast object490 can be regarded as a parent object, and the next level object 400can be regarded as a child object.

The operation of the cast object 490, 400 will be explained using anillustrative hypothetical example. Assume that the cast object 490 isinserted in a design. A user may insert the top-level cast object 490into a design for any of the reasons stated in the previous section.Further, assume that a 16-bit data set type is indicated on node 492 andthat a 4-bit data set is propagated to node 494. During the synthesisprocess, when all of the inputs nodes of the top-level cast object 490have data set information propagated to them, the flatten algorithm willcall the next level variant cast object 400 referenced by the top-levelcast object 490.

The flatten algorithm will insert object 400 in the design in place ofthe top-level cast object 490. Node 408 of object 400 is connected toreceive data set type information propagated to node 492 of object 490.

Node 412 of object 400 is connected to receive the data set propagatedto node 494 of object 490. Node 416 of object 400 is connected toprovide data set information other objects (not shown) in the designconnected to node 496 of object 490. Thus, the data set type on node 408is to be cast to the data set on node 412.

FIG. E1 shows details of the variant cast object. Briefly stated thevariant cast behavior object 400 of a presently preferred embodiment ofthe invention first casts up to a known data set and then casts backdown to a desired data set type. Referring to the illustrative drawingof FIG. E1, there are shown the constituent behavior objects of a castbehavior object 400. An output node of a castup behavior object 402 isconnected to a data set-input node of a castdown behavior object 404 bytransport object 406. Node 408 is connected to a type-input node of thecastdown object 404 by transport object 410. Node 412 is connected to adata set input node of the castup object 402 by transport object 414. Anoutput node of the castdown object 404 is connected to node 416 bytransport object 418.

A variant form of the cast behavior object 400 is a top-level objectthat is recursively resolved during the synthesis process. The data setinput node and the data set output node of the castup behavior object402 is variant type. The type-input node, the data set input node andthe data set output node of the castdown behavior object 404 are varianttype. The behavior of the cast behavior object in any given design,therefore, is determined through the data set propagation process. Thatis, the exact nature of the casting depends upon the type value on node408 and the data set on node 414.

More specifically, the variant form of the cast behavior object 400comprises two other variant objects, namely a castup behavior object 402and a castdown behavior object 404 each of which includes variant inputnodes. The castup and castdown objects 402 and 404 serve as tokens,during the synthesis (compiler) process, causing the synthesis process(compiler) to reference corresponding detailed drill downs of thesebehaviors in the object library. The illustrative drawing of FIG. E2shows a variant castup object 418 referenced using the castup object 402object of FIG. E1. The illustrative drawing of FIG. E3 shows a terminalleaf castup object 420 referenced using the castup object 402. Theillustrative drawing of FIG. E4 shows a variant castdown object 422referenced using the top-level castdown object 404 of FIG. E1. Theillustrative drawing of FIG. E6 shows an explicit castdown objectreferenced by the castdown object 404.

FIG. E2 shows details of a variant castup drill down 418. Node 408-1receives as input a data set type. An input node of data set type doubleand fill behavior object 424 is connected with node 408-1 by a branch ofcomposite transport object 426. One input node of variant collectorobject 428 is connected to an output node of the data set type doubleand fill behavior object 424 by transport object 430. Another input nodeof variant collector object 428 is connected to node 408-1 by transportobject 430. A variant input node of the castup behavior object 402 (thecastup object 402 is self-referential) is connected to an output node ofthe variant collector object 428 by transport object 432. Node 434 isconnected to an output node of castup object 402 by transport object436.

The operation of the castup behavior object 402 during a synthesisprocess shall be explained through a hypothetical example in which thedata set type on node 408 in a design is a nibble (4 bits wide). By wayof overview, a present embodiment, the castup 402 behavior objectsresults in a casting of a data set type to a prescribed higher leveldata set type. In this example, assume that the higher-level data settype is a Quad-word (Q-word) (64 bits wide).

The illustrative diagram of FIG. E5 pictorially represents in generalterms the evolution of the castup behavior object during a synthesisprocess where the data set type on node 412, 412-1 in a design is nibbletype (4 bits wide). In the course of the synthesis process, the variantcastup behavior object 402 will be instantiated four times before itreaches its terminal leaf 420 illustrated in FIG. E3. The data setpropagation process, discussed in detail elsewhere in this disclosure,will drive this instantiation process. In a present embodiment of theinvention, a data set cannot be propagated beyond an object that has notbeen resolved to its terminal leaf (atomic form). Hence, it will beappreciated from FIG. E1, that the castup object 402 must be resolved toits terminal leaf in FIG. E3 before the castdown object 404 can bedriven to resolution by the data set propagation process.

Referring to FIG. E5, the castup behavior object in its firstinstantiation 402-1 converts the 4-bit nibble data set to an 8 bit bytedata set. A first instantiation of the variant collector object 428-1 isshown with two 4-bit data set type inputs and an 8-bit data set typeoutput. Its second instantiation 402-2 converts the 8-bit byte data settype to a 16-bit word data set type. A second instantiation of thevariant collector object 428-2 is shown with two 8-bit data set typeinputs and a 16-bit data set type output. Its third instantiation 402-3converts the 16-bit word data set type to a 32 bit Dword (Double word)data set type. A third instantiation of the variant collector object428-3 is shown with two 16-bit data set type inputs and a 32-bit dataset type output. Its fourth instantiation 402-4 converts the 32-bitDword data set type to a 64 bit Qword (Quad word) data set type. Afourth instantiation of the variant collector object 428-4 is shown withtwo 32-bit data set type inputs and a 64-bit data set type output. Thus,the castup object 402, 418 evolves from an instantiation that receives a4 bit data set input on node 412, 412-1 to an instantiation thatreceives a 32 bit input on input node 412, 412-1. In a finalinstantiation, a terminal leaf 420 receives a 64 bit data set type onnode 412-2.

A fifth instantiation of the castup object 402 is the terminal leaf 420shown in FIG. E3. The terminal leaf object 420 includes an input node438 connected to an output node 440 by a transport object 442. Each ofthe input and output nodes and transport object is Qword data set type.The terminal leaf castup object 420 is the atomic version of the castupbehavior in this example.

The following is a more detailed description of the behavior of thecastup object drill down 418 of FIG. E2. It will be appreciated thateach of the instantiations diagrammatically represented in FIG. E5involve the castup drill down object 418. There is a different data settype on the input node 408-1 for each instantiation in the evolution ofthe castup object (i.e. 4 bit, followed by 8 bit, followed by 16 bitfollowed by 32 bit). Conversely, there is a different data set type onthe output node of variant collector object 428 during eachinstantiation in the evolution of the castup object (i.e., 8 bit,followed by 16 bit, followed by 32 bit, followed by 64 bit). Thecollector object 428 evolves from 428-1 to 428-2 to 428-3 to 428-4during successive instantiations of the castup object 418.

Continuing with the above example, assume that a 4 bit (nibble) data settype is propagated to (or is provided as a constant value data set type)to node 412 in FIG. E1. Transport object 414 transports (propagates) the4 bit data set type to the input node of the castup object 402. Sincethe only input node of the castup object 402 is variant type and has adefined data set propagated to it (or otherwise defined), the synthesisprocess calls the flatten process to resolve the castup object 402.

It will be appreciated that the synthesis process regards the castupobject 402 in FIG. E1 as a token that references an equivalent functionin an object library. Referring to FIG. E9, there is shown a portion ofthe object library that pertains to the logical function. The top-levelcastup behavior object 402 references two lower level behavior objects418 and 420. Object 418 is variant. Object 420 is explicit; it has a64-bit data set type input node. In the present example, at thisjuncture of the synthesis process, the data set type on the input nodeof the castup object is 4-bit type. There is no match to the explicitobject 420. Thus, the flatten algorithm calls the variant castup object418 and inserts it into the design in place of the top-level castupobject 402.

Once the castup object 418 has been inserted into the design, the 4-bitdata set type on node 412 in FIG. E1 is propagated to node 412-1 in FIG.E2. The 4-bit data set type is propagated to composite transport object426. The 4-bit data set type is propagated to the input node of data settype double and fill behavior object 424. The 4-bit data set type alsois propagated to the least significant bit input node of the data setcollector object 428.

Since the only input node of the of data set type double and fillbehavior object 424 is variant type and has a defined data setpropagated to it, the synthesis process calls the flatten process toresolve the data set type double and fill behavior object 424. Thebehavior of object 424 is to create a new data set of the same type(4-bit at this juncture of the data set propagation process). The object424 assigns a constant value (a logical zero (0) value in a presentembodiment) to each bit in the newly created data set. Object 424outputs the newly created data set to the most significant bit inputnode of the collector object 428.

At this juncture of the propagation and flatten process, a 4-bit dataset type with bit values XXXX is provided on the least significant bitsnode of the collector object 428. Also, at this juncture of thepropagation and flatten process, a 4-bit data set type with constant bitvalues 0000 is provided on the most significant bits node of thecollector object 428. Propagate data sets process causes the collectorobject 428 (actually 428-1 in FIG. E5) to output an 8-bit data set typeon its output node. More specifically, the data set type is of the form0000XXXX. The four most significant bits are constant values, zero inthe preferred embodiment. The four least significant bits are variable,either logical 1 or logical 0.

Next, transport object 432 propagates the 8-bit data set to the inputnode of the castup object 402. Since the only input node of the castupobject 402 is variant type and has a defined data set propagated to it(8-bit at this juncture of the process), the synthesis process againcalls the flatten process to resolve the castup object 402. The sameprocessing pattern repeats, this time with an 8-bit data set of the form0000XXXX provided on input node 412-1. The result of this next iterationof the processing pattern is a 16-bit pattern of the form00000000000XXXX propagated from the output node of collector object 428(428-2 in FIG. E5). The 16-bit data set type is propagated by transportobject 432 to the input node of the castup object 402. The synthesisprocess again calls the flatten process to resolve the castup object402. The same processing pattern repeats, this time with the 16-bit dataset.

As best illustrated in FIG. E5, this recursive-processing patternrepeats until there is an explicit match between the top-level castupobject 402 and the terminal leaf object 420 of FIG. E3. The terminalleaf 420 is reached following four iterations of the recursivecastup-processing pattern. The result at that juncture of the castprocessing is the insertion of the terminal leaf object 420 of FIG. E3into the design in place of the variant castup object 402 of FIG. E1.Moreover, the data set type on node 416-2 of terminal leaf object 420has constant values (logical 0 in the preferred embodiment) in theleading (most significant) sixty (60) bit positions and has four (4)variable value XXXX bits in the four least significant bit positions.Thus, the result is a casting up of the 4-bit type data set to a 64-bitdata set. Moreover, a 64-bit data set is created in which constantvalues (0's in the preferred embodiment) are packed into the 60 mostsignificant bit locations, and the four least significant bit locationsremain variable.

Referring again to FIG. E1, at this juncture in the synthesis processassume that transport object 406 has propagated the above-described64-bit data set to the data set input node of the castdown behaviorobject 404. Furthermore, assume that in the example the data set type onnode 408 is 16-bit (word) type and that the 16-bit type has beenpropagated by transport object 410 to the type input node of thecastdown object 404. Thus, the cast of type is a cast of a 4-bit typedata set (node 412) to input to a 16-bit type data set (node 408).

Thus, at this juncture in the synthesis process, the flatten algorithmis called. Remember that synthesis process regards the castdown object404 as a token that references a lower level (drill down) behavior. Ingeneral, the flatten algorithm searches the object library forappropriate lower level objects to insert into a design for higher levelobjects for which a data set has been propagated to all input nodes.Assume that in this example, at this juncture of the data setpropagation process, the flatten algorithm observes the data set typeshave propagated to each of the input nodes of the castdown object 404 inFIG. E1. The flatten process then searches the object library for anexplicit match to a lower-level castdown object. Referring to theillustrative drawing of FIG. E7, there is shown a representation of theportion of an object library relating to the castdown behavior. Theobject library is hierarchical. A top-level castdown object 404references both a variant castdown object 422 and an explicit cast downobject 458. The variant type castdown object has variant type data setson each of its nodes. Details of the variant type castdown object 422are shown in FIG. E4. Details of the explicit castdown object 458 areshown in FIG. E6. The explicit castdown object 458 has a 64-bit data settype on each of its nodes.

The search is for a lower-level castdown logical behavior object thathas the same explicit data set types on its input nodes that have beenpropagated to the input nodes of the castdown object 404 at the currentjuncture of the synthesis process. At his juncture in the synthesisprocess, the type-input node of castdown object 404 has a 16-bit dataset type propagated to it. Also at his juncture in the synthesisprocess, the data set input node of the castdown object 404 has a 64-bitdata set type propagated to it. Referring to the object library portionof FIG. E7, there is no castdown library object with an explicit match.That is, there is no castdown library object with an explicit 16-bittype input node and an explicit 64-bit data set input node. Thus, thesynthesis engine selects the variant type castdown object 422 shown inFIG. E4 for insertion into the design in palace of the top-levelcastdown object in FIG. E1.

By way of overview, the resolution of the castdown object 404 in thisexample will result in the replacement in the example design of theobject 404 in FIG. E1 with the collection of objects 478 shown in FIG.E8. During the resolution process, first data set exposer 480 is addedto the design. Next, dataset exposer 482 is added to the design.Finally, transport object 484 is added to the design.

In this example, the overall purpose of the cast operation is to cast a4-bit type data set back down to a 16-bit type data set. Remember, inthis example, the castup object 402 in FIG. E1 causes the 4-bit data setpropagated to node 412 of FIG. E1 to be cast up to 64-bit type. Also,remember that the input on node 408 in FIG. E1 is 16-bit data set type.Thus, the role of the castdown object in the design in this example isto cast down a 64-bit data to the 16-bit type data set.

By further way of overview, the portion of the data set propagationprocess that occurs with respect to the collection of objects 478 inFIG. E8 shall be explained. It will be appreciated that such data setpropagation cannot occur until after the castdown object 404 of FIG. E1has been resolved. However, the following explanation will give insightinto the resolution process. During data set propagation, the 64-bitdata set propagated by the castup object, which has been resolved to theterminal leaf object 420 of FIG. E3, is propagated to transport object484. Recall that the leading 60 bits on the propagated In a finaldesign, these lower four bits can carry the information of a data setprovided on node 412 in FIG. E1. An input node of data set exposer 482is connected to transport 484. A least significant bits output node ofthe data set exposer 482 is connected to an input node of data setexposer 480 by transport object 486. A most significant bits output ofdata set exposer 482 is unconnected. A least significant bits outputnode of the data set exposer 480 is connected to an transport object488. A most significant bits output of data set exposer 480 isunconnected.

Thus, as the 64-bit data set is propagated through the collection ofobjects 478 of FIG. E8, it is cast down to a 16-bit data set type whileretaining the 4 bits from input node 412 of FIG. E1 in the lower fourbit positions. Specifically, data set exposer 482 propagates the lower32 bits to transport object 486. Data set exposer propagates the lower16 bits to transport object 488. The collection of objects 478 in FIG.E8 do not propagate the upper 48 bits (on transport 484).

Referring to FIG. E4, there are shown the constituent objects of thevariant castdown object 422. It includes a type input node 408-1 that isto be connected in a design to receive information identifying a dataset type to which another data set (that on node 454-1) type is to becast to. Node 408-1 is connected to an input node of data set typedouble and fill behavior object 462 and to one input node of data setexposer object 464 by composite transport object 466. An output node ofthe of data set type double and fill behavior object 462 is connected toanother input node of data set exposer object 464 by transport object468. Input node 454-2 is connected by transport object 468 to a data setinput of a castdown object 404. Input node 454-1 is to be connected in adesign to receive a data set that has been castup by castup object 402and now is to be cast back down to a desired data set type indicated onnode 408-1. An output node of the data set exposer 464 to a data settype input node of the castdown object 404 by transport object 470. Anoutput node of the castdown object in FIG. E4 is connected to an inputnode of data set exposer 472 by transport object 474. A leastsignificant bit output node of data set exposer 472 is connected to node456-1 by transport object 476. Most significant bit output node of dataset exposer 472 is unconnected.

Referring to the illustrative drawing of FIG. E6, there are shown theconstituent objects of the explicit castdown object 458. It includesthree nodes 408-2, 454-2 and 456-2. Node 408-2 is an input node that isto be connected to receive the data set type that a data set is to becast to. Node 454-2 is an input node that is to be connected to receivesa data set that is to be cast to the type specified on node 408-2. Node456-2 is an output node that is to be connected to propagate theresulting data set. Each node in FIG. E6 is defined as having a 64-bitdata set type. A 64-bit data set type transport object 460 connectsnodes 408-2 and 456-2. The type-input node 452 is left dangling. It willbe appreciated that this dangling node 408-2 will result in the removalof all objects connected to it by the sourceless and sinkless (trimming)algorithm.

We now return to the resolution of the castdown object 404 to explainhow the castdown object 404 of FIG. E1 is evolved into the collection ofobjects 478 in FIG. E8. Assume that at his juncture of the synthesisprocess, 16-bit data set type has been propagated to the type-input nodeof castdown object 404. Further assume that the 64-bit data set, thathas been cast up by castup object 402, has been propagated to the dataset input node of castdown object 404.

The flatten algorithm references the object library to find a castdownobject that matches the data set types on the input nodes of thecastdown object at this juncture of the synthesis process. The closestmatch is the variant castdwon object 422, which is inserted into thedesign in place of the top-level castdown object 404. Specifically, node408-1 of object 422 is connected to receive data set type propagated tothe type node of object 404. Node 454-2 of object 422 is connected toreceive a data set propagated to the data set node of object 404. Node456-1 of object 422 is connected to provide an output data set totransport object 418.

It will be appreciated that at this juncture in the synthesis process, afirst variant select object 480 is inserted in the design as part of theinsertion of object 422 into the design.

Next, the data set information is propagated to the castdown object 422.The 16-bit data set types on node 408-1 is propagated by transportobject 466 to an input node of data set type double and fill behaviorobject 462. The behavior of object 462 is to create a new data set ofthe same type (16-bit at this juncture of the data set propagationprocess). The object 462 assigns a constant value (a logical zero (0)value in a present embodiment) to each bit in the newly created dataset. Object 462 outputs the newly created data set to the mostsignificant bit input node of the collector object 464. Meanwhile the16-bit data set type on node 408-1 also is propagated via transportobject 466 to a least significant bits input node of data set collectorobject 428. The data set collector object 464 propagates a 32-bit dataset to transport object 470.

At this juncture of the synthesis process, a 32-bit type data set hasbeen propagated to the type-input node of the castdown object 404. Also,a 64-bit data set has been propagated to the data set input node of thecastdown object 404. Thus, the flatten algorithm again searches theobject library for the closest match. Referring to FIG. E7, there is noobject in the object library for the castdown behavior that has anexplicit 32-bit type input and an explicit 64-bit data set input. Thus,flatten algorithm again selects the variant castdown object 422 andinserts it in place of the top-level castdown object 404 in FIG. E4.

It will be appreciated that at this juncture in the synthesis process, afirst variant select object 482 is inserted in the design as part of theinsertion of castdown object 422 into the design.

Again, the data set information is propagated through the castdownobject 422. This time, there is a 32-bit data set type on node 408-1that is propagated by transport object 466 to an input node of data settype double and fill behavior object 462. The behavior of object 462 isto create a new data set of the same type (32-bit at this juncture ofthe data set propagation process). The object 462 assigns a constantvalue (a logical zero (0) value in a present embodiment) to each bit inthe newly created data set. Meanwhile the 32-bit data set type on node408-1 also is propagated via transport object 466 to a least significantbits input node of data set collector object 464. Object 462 outputs thenewly created data set to the most significant bit input node of thecollector object 464. The data set collector object 464 propagates a64-bit data set to transport object 470.

At this juncture of the synthesis process, a 64-bit type data set hasbeen propagated to the type-input node of the castdown object 404. Also,a 64-bit data set has been propagated to the data set input node of thecastdown object 404. Thus, the flatten algorithm again searches theobject library for the closest match. This time there is an explicitmatch to castdown object 458 in the object library portion of FIG. E7.In particular, castdown object 458 in the object library has an explicitmatch to a 64-bit type input and an explicit 64-bit data set input.Thus, this time the flatten algorithm selects the explicit castdownobject 458 and inserts it in place of the top-level castdown object 404in FIG. E4.

It will be appreciated that at this juncture in the synthesis process,the transport object 484 is inserted in the design as part of theinsertion of castdown object 422 into the design.

Thus, in this example, in the course of the synthesis process the castupobject 402 of FIG. E1 is resolved to the terminal leaf object of FIG.E3. The data set on node 494 in FIG. E1A first is cast up to aprescribed data set type. In this case, the prescribed data set type is64-bit type. The 4-bits of the data set propagated to node 494 are inthe lower four bit positions of the 64-bit data set. Moreover, thecastdown object 404 of FIG. E1 is resolved into the collection ofobjects 478 in FIG. E8. The 64-bit data set propagated to the castup ispropagated from transport object to the exposer object 482. The lower 32bits are propagated from the exposer object 482 to exposer object 480.The lower 16 bits are propagated by exposer object 480 to transportobject 488. Therefore, the 4-bit data set on node 494 of top-levelobject 490 of FIG. E1A has been cast to the 16-bit data set type on node492 of object 492. The resulting data set is propagated on transportobject 488 of FIG. E8 created as part of the resolution of top-levelcast object 490.

The resolution of variant objects 424 and 462, variant data set exposers480 and 482, variant collector 428 and variant exposers 464 and 472 intoexplicit type objects of the types discussed in this section will beappreciated from discussions herein and from the discussions elsewherein this disclosure. Specifically, the flatten and the data propagationalgorithm collaborate to resolve these variant objects in the course ofthe resolution of the cast object 490. The same general processes usedto resolve the cast object 490 in general are used to resolve theseobjects in particular.

It will be appreciated that in a cast process in accordance with apresently preferred embodiment of the invention, a data set to be castup to a desired data set type initially is cast up to a known data settype large enough data set to encompass the desired data set type. Thedata set then is cast down from the known data set type to the desireddata set type.

Propagate Constants Process

The propagate constants process resolves atomic objects to whichconstants are connected. In a present embodiment, constant values arerepresented in binary format, i.e. logical 1 or logical 0. The propagateconstants process operates by applying atomic object resolution rules toatomic objects that have constant value inputs during the constantpropagation process. Basically, the object resolution rules perform theactual atomic operations specified by the atomic object according to theconstant values applied to them. The schematic diagrams of FIGS. L5-L10illustrate the atomic object resolution rules implemented by thepropagate constants process of a current embodiment of the invention.

FIGS. L1-L2 show the atomic object resolution rules for an atomicINVERTER operator. In FIG. L1, if a logic 0 constant is provided to itsinput node then a transport object replaces the INVERTER with a logic 1constant connected to its input node. In FIG. L2, if a logic 1 constantis provided to its input node then a transport object replaces theINVERT operator with a logic 0 constant connected to its input node.

FIGS. L3-L4 show the atomic object resolution rules for an atomic ANDoperator. In FIG. L3, if a logic 0 constant is provided to one of itsinput nodes then a transport object with a logic 0 constant connected toits input node replaces the AND operator. An output node of a transportobject or the constant value, whichever is the case, connected to theother input node of the AND operator is left dangling. In FIG. L4, if alogic 1 constant is provided to one of the AND operator's input nodesthen the AND operator is replaced with the transport object or constantvalue, whichever is the case, connected to its other input node. Thelogic 1 constant is left dangling.

FIGS. L5-L6 show the atomic object resolution rules for an atomic ORoperator. In FIG. L5, if a logic 1 constant is provided to one of itsinput nodes then a transport object with a logic 1 constant connected toits input node replaces the OR operator. The transport object orconstant value, whichever is the case, on the other input node is leftdangling. In FIG. L6, if a logic 0 constant is provided to one of the ORobject's input nodes then the OR operator is replaced with the outputnode of a transport object or constant value, whichever the case may be,connected to its other input node. The logic 0 constant value is leftdangling.

FIGS. L7-L10 show the atomic object resolution rules for the Assignmentoperator. In FIG. L7, if a logic 0 constant is provided to the inputnode of an assignment operator, then the assignment operator is replacedwith a transport object with a logic 0 constant connected to its inputnode. In FIG. L8, if a logic 1 constant is provided to the input node ofan assignment operator, then the assignment operator is replaced with atransport object with a logic 1 constant connected to its input node. InFIGS. L9-10, if the clock input of a clocked assignment operator haseither a logic 1 or a logic 0 constant value applied to it then thatclocked assignment operator is replaced with two dangling nodes.

The illustrative block diagram drawings of FIGS. L11-L14 together with areference to FIG. D3 shall be used to explain how the propagatetransport process can be used to drive parameterized selective symbolsubstitution in accordance with a presently preferred embodiment of theinvention. In other words, an explanation is provided for of thecontribution by the propagate constants process to the resolution of aparameterized polymorphic object into an explicit object. FIGS. L11-L14,illustrate the combined operation of the propagate data sets process andthe flatten process in reducing a variant polymorphic behavior objectinto its atomic elements. Once an object has been reduced to its atomicelements, then according to the propagate constants atomic objectresolution rules, the atomic objects will be resolved in accordance withtheir atomic operations as explained in FIGS. L1-L13.

The propagate constants process contributes to the resolution of aparameterized variant behavior object by further transforming the atomicobjects associated with a control portion of such parameterized objectin accordance with the atomic object resolution rules. The applicationof these rules by the propagate constants process gives effect to anequivalent function associated with a control portion of such behavioralobject in the context of the synthesis process itself. Instead ofincluding the atomic objects derived from the resolution of a variantbehavior object in the control portion in a netlist, the atomic objectsin the control portion are used to produce values in the context of thesynthesis process itself. These values are used to control theresolution of other portions of the parameterized polymorphic behaviorobject.

Briefly stated, in a current embodiment of the invention, a parameterthat is used to parameterize a parameterized polymorphic behavior objectcan be propagated in a design using the propagate constants process. Theconstants propagated to resolve atomic objects of a control portion ofthe behavior object can produce one or more values that give effect tosuch a parameter. That is the values produced by the atomic objectresolution rules are used to make selections among different possibleresolutions of the polymorphic object in the context of the synthesisprocess itself. As explained in FIGS. D1-10 a select object can bedriven by the values produced by the atomic resolution rules.

Referring to FIG. L11, there is shown the variant compare object of FIG.D3. As explained in another part of this disclosure, the variant compareobject 250 is part of the control portion 280 of a parameterizedpolymorphic ADD behavior object 230. Information rate is the parametercontrolling the selective synthesis of the ADD behavior object 230. Thecompare object 250 in FIGS. D3 and L11 has variant type input nodes Aand B and has three bit-type output nodes A=B, A>B and A<B as shown. Thevariant type compare object in FIG. L11 is a top-level compare object.It references a next level variant type behavior compare object 250′illustrated in FIG. L12. The variant compare behavior object 250′includes two instances of top-level compare object 250, two variant typedata set exposer objects 720 and three multiplexer behavior objects 722,724 and 726 connected as shown. The top-level compare object 250 alsoreferences atomic level add object 250′, four instances of which areshown in FIG. L14. The compare behavior of the variant compare objectwill be understood by those skilled in the art from the descriptions inthis and other section of this disclosure and shall not be explainedfurther.

Referring to FIG. D3, assume in this example that the information rateis represented by a 4-bit value that requires a 4-bit data set type.Assume also that two constants representing two information rates areprovided on source nodes 264 and 266 in FIG. D3. Further assume that the4-bit data set type is provided on each of nodes 264 and 266. Asexplained in other sections of this disclosure the information rate andthe data set type on source nodes 264 and 266 can be acquired or copiedfrom other nodes in the design database in the context of or during thesynthesis process itself. In particular, attribute rules specified onnodes 264 and 266 can be used to acquire or copy such information intothese nodes during the synthesis process itself. It will be appreciatedthat the acquisition of parameters used to resolve a parameterizedpolymorphic behavior object in the context of the synthesis process usedto resolve the object is a powerful feature of the selective symbolicsubstitution process of the present invention.

Referring to FIGS. L11-L14, the propagate data sets and flattenprocesses first resolve object 250 shown in FIG. L11 into object 250′shown in FIG. L12. Next, the propagate data sets and flatten processesresolve the object 250′ shown in FIG. L12 into object 250-1 shown inFIG. L13. Finally, the propagate data sets and flatten processes resolveobject 250-1 shown in FIG. L13 into object 250-2 shown in FIG. L14.Object 250-2 includes four instances of the atomic level compare object250″.

Assume that 4-bit constant values (using logic 1 and logic 0)representing the information rates on nodes 264 and 266 are provided tothe input nodes of the atomic level operators. That is two logic values(A0, B0) are provided as inputs to one instance of the atomic levelcompare object 250″. Two logic values (A1, B1) are provided as inputs toanother instance of the atomic level compare object 250″. Two logicvalues (A2, B2) are provided as inputs to another instance of the atomiclevel compare object 250″. Two logic values (A3, B3) are provided asinputs to another instance of the atomic level compare object 250″.

In this example, now that these logic values are provided directly toatomic level objects, the propagate constants process will apply theatomic object resolution rules to resolve each of the atomic object,giving effect to their operations in the context of the synthesisprocess itself. The resulting values are used to drive the otherbehavior objects in the control portion 280 of FIG. D3, which in turn,controls selective synthesis of the parameterized polymorphic ADDbehavior object 230.

Propagate Information Rate Process

The propagate information rate process propagates information rateinformation from an output node of one object to the input node ofanother object. For a given output node, the propagate information rateprocess involves first determining whether an information rate valueassociated with the given output node is “set”, that is whether it has avalue other than its default value. The propagate information rateprocess also determines whether or not an information rate value is setfor the input node connected to the given output node. If theinformation rate value is set for the given output node but is not setfor the connected to input node, then the propagate information rateprocess copies the information rate associated with the given outputnode to the connected to input node.

If the information rate value is not set for the given output node thenthe propagate information rate process attempts to generate aninformation rate from attribute information of the given output node.The attributes of the given output node may include attribute calculatorinformation that may specify parameters and operations to be used tocalculate the information rate. The attribute calculator also mayinclude information about location of such parameters in the designdatabase. Moreover, that location information may describe the locationof the parameter information in terms of the relative locations of thegiven output node and another node of a composite object of which bothnodes are members. The description of location information in relativeterms is significant since it can serve to isolate the generation ofinformation rate information from the details of any particular design.Rather the information rate generated for the given output node willdepend upon the information rate, or other parameter, propagated to theother node in the relative location described in the attributecalculator. Thus, the generated information rate can be made to becontext dependent. That is, the generated information rate can be madeto depend upon whatever information rate (or other parameter deemedrelevant) has been propagated to, generated by or otherwise is inpossession of that other node in the relative location in the context ofthe synthesis process.

Briefly, the attribute calculator in a present embodiment of theinvention is structured as follows.

Token, Token 2, Operator

An example of tokens is as follows.

##N2.C

In the syntax of a present embodiment of the invention, the symbol #signifies a relative location being the next object up in the compositeobject of which the given output node is a member. The symbols ##signifies two objects higher up in the composite object of which thegiven output node is a member. N2 signifies the second node of theindicated higher level object. The symbol C represents a data set type.

An example attribute calculator information is as follows.

##N2.C, ###N3.C, +

In the syntax of a present embodiment of the invention, the aboveattribute calculator information causes the addition of the informationrate at node 2 to the information rate at node 3. Node 2 is located atan object two levels up in the composite object, and node 3 is locatedthree levels up in the composite object.

It will be appreciated that numerous different operators can be employedsuch as select the greater of or select the lesser of or divide by ormultiply be, etc. Moreover, it will be appreciated that the attributecalculator to generate information rate can use different parametersother than information rate. For instance, information rate mightinstead be calculated based upon the data set type propagated to anothernode in prescribed relative position.

Alternatively, an attribute calculator may result in the use of aninformation rate suited to a specific to a target hardware environment.For example, it may be known that the behavioral description is to besynthesized into a design targeted to a particular FPGA architecture. Inthat case, the attribute calculator may obtain information from theother node in the prescribed relative position indicating the targetFPGA hardware and a particular information rate for that hardware. Inthat case, the information rate could be calculated, or assigned, basedon the particular target hardware.

Continuing with the explanation of the generate information rateprocess, if an information rate is successfully generated for the givenoutput node, then the propagate information rate process attempts topropagate the information rate as described above. On the other hand, ifthe information rate is not generated then no information rate ispropagated by the given output node. For example, the information ratemight not be generated because one or more other nodes in the prescribedrelative positions may not yet have propagated to them the requiredinformation rate or other parameter.

Referring to FIG. D3, it will be appreciated that the output nodes ofeach of source objects 264 and 266 include a respective attributecalculator as part of its respective attributes. The attributecalculator of source object 264 identifies an output node of sourceobject 256 as having the needed information rate information. Theattribute calculator of source object 266 identifies an output node ofsource object 258 as having the needed information rate information.

Flatten Process and Select Equivalent Function Processes

The flatten process operates as follows. For a given composite object,if all inputs to all connected nodes are known (data set types andconstant values) then flatten the object. That is, call the selectequivalent function process which selects an appropriate equivalentobject to be substituted into the design by the flatten process in placeof the variant behavior object. Then substitute the selected object intothe design in place of the given object.

The select equivalent function process makes a selection among one ormore lower-level objects referenced by a given composite object that hasprompted the call to the select equivalent function process. Eachcandidate for substitution must have an equivalent behavior asdetermined using The Axiom System discussed in another section of thisdisclosure. Once candidate objects have been identified, the selectequivalent function process attempts to identify the best match betweena candidate object and the given composite object. A scoring system isused to determine the object with the best match the composite object tobe replaced. Factors such as closeness of data set type and closeness ofinformation rate and closeness of action latency are examples of factorsconsidered in the scoring system. The manner in which these factors areweighted against each other in the scoring system may be adjusteddepending upon design goals.

FIGS. M1-M3 illustrate the process whereby the flatten processsubstitutes into a design a lower-level object in place of a givencomposite object. FIG. M1 shows an example of a hypothetical higherlevel composite object 740. FIG. M2 shows an example of a hypotheticallower level object 742 selected by the select equivalent functionprocess as the best match to the higher level object 740. FIG. M3 showsthe lower level object 724 substituted into the design in place of thehigher level object 740. Note that transport objects 744 and 746 areconnected to object 740 in FIG. M1, and transport objects 744 and 746are connected to object 242 in FIG. M3.

The rules substitution process is summarized with reference to theexample in FIGS. M1-M3 as follows. Remove the high level compositeobject 740 from the design. Identify transport objects 748, 750 on thelower level object 742 that are to be connected to other transportobjects 744 and 746 of the design. Remove source and sink nodes 752, 754from the identified transport objects. Connected the identifiedtransport objects into the design. Add the remaining behavior of thelower level object to the design database, leaving dangling sources andsinks 756, 758 for transport objects 760, 762 that are not to beconnected into the design. These dangling sources and sinks 760, 762will be removed later by the remove sourceless and sinkless process.

Propagate Data Sets Process

The propagate data sets process operates as follows. For all objects, ifthe data set type of a given output node is known, i.e. it is notvariant, and the given output node is connected to an input node ofanother object, and the data set type of the input node of the otherobject is variant, then copy the data set type of the given output nodeto the connected to input node. For transport objects, add thefollowing. If the input node of the transport object is not variant,then copy the data set type of the input node to all output nodes of thetransport object.

Remove Sourceless and Sinkless Objects Process

The remove sourceless and sinkless objects process operates as follows.Remove each unconnected sink object that is not at a top level of thedesign hierarchy. A top-level sink may in fact terminate in the userinterface and should not be removed. For instance it might be connectedto supply information to a user interface graphical control element suchas a meter, graph or display. Such top-level objects are labeled as suchin a current implementation of the invention. Also, remove eachunconnected source object. For sink objects, follow each transportconnected to such unconnected sink object (nodes are doubly linked toeach other) to determine whether the transport has output effects on anyother objects in the design. If it does not, then remove the transportobject. For unconnected source objects, remove the transport objectconnected thereto and all of its output nodes. If the removal of atransport object leaves another object in the design unconnected (otherthan the unconnected source object of course) then remove the otherobject as well.

Compress Transports Process

The compress transports process operates as follows. If an output nodeof one transport object is connected to the input node of anothertransport object then compress the two transport objects into a singletransport object. Remember that a transport object can have more thanone output node. The compress transports process is helps to removeredundant transport objects from the design database. It will beappreciated that such redundant transport objects can result from theflatten process, for example.

Note that the transport junction of FIG. 15 does not indicate theexistence of multiple transport objects. Rather, it is a mechanism usedin the graphical user interface environment of a current embodiment ofthe invention to more clearly depict the branching within a singletransport object.

Generate Constants Process

The generate constants process operates as follows. A source node mustoriginally propagate a constant value. Assume that the source node ofFIG. N1 has acquired the value 9. For instance, the value 9 mightsignify an information rate. The value 9 may have been acquired as partof the propagate information rate process through the action of anattribute calculator. In any case, in this example, the generateconstants process constructs the hierarchy of collector objects shown inFIG. N2. Basically, the individual logic values representative of thevalue 9 (1001 is 9 in base two) are provided to a descending hierarchyof collector objects that terminate in a transport object having anexplicit data set type, 4-bit type, in this example.

Referring to FIGS. L11-L14, assume that respective output transportobjects are connected to the respective input A and B nodes of object250. Moreover, assume that each respective transport object correspondsto transport object 782 of FIG. N2 and is part of respective descendinghierarchy of collector objects identical to those that in FIG. N2, butwith different constant values applied to the input nodes of thecollector objects. (That is assume that source object in essence is inthe position akin to that of either source node 264 or 266 of FIG. D3.)Continuing with the example, it will be appreciated that the 4-bit typedata sets will be propagated to the input nodes A and B of object 250 ofFIG. L11, resulting in the resolution of the object 250 in FIG. L11 intothe object 250-2 of FIG. L14 according to the processing describedabove.

At the end of the processing in FIGS. L11-L14, a respective descendinghierarchy like that in FIG. N2 will be connected to each of the twoexposer objects 720 in FIG. L13. Note the symmetry between thedescending hierarchy of collector objects in FIG. N2 and the ascendinghierarchy of exposer objects in FIG. L13. They are symmetrical datastructures.

Remove Exposer and Collector Objects

The remove exposer and collector process operates as follows. If atransport object connects directly to both a collector object and anexposer object, and the collector object and the exposer object aresymmetrical (i.e. same data set types), then replace the collectorobject and the exposer object with transport objects that connect therespective input transport objects and output transport objects of therespective removed collector and exposer objects. Repeat the process.

In the event that the input nodes of the collector objects are connectedto constant values, the process can result in the removal of allcollector and exposer objects leaving only constant values connected totransport objects. It will be appreciated that this process can be usedto connect constant values on nodes 264 and 266 of FIG. D3 to the inputnodes of the atomic objects 250″ of FIG. L14. Note that consistent withthe operation of the remove exposers and collectors process, theexposers shown in FIG. L13 are removed in FIG. L14, and constant valuesA0A1A2A3 and B0B1B2B3 are applied directly to the input nodes of theatomic operators.

FIGS. O1-O3 illustrate the operation of the remove collector and exposerobjects process. FIG. O1 shows the original object structure thatincludes collector objects C1, C2, and C3 and exposer objects E1, E2 andE3. FIG. O2 shows the removal of collector object C3 and exposer objectE1 and the connection of collector object C1 to exposer object E2. FIG.O2 also shows the connection of collector object C2 to exposer objectE3. FIG. O3 shows the removal of all remaining collector and exposerobjects and the connection of the constant values directly to the fourremaining transport objects.

It will be appreciated that the remove collector and exposer objectsprocess also can be used to simplify portions of the design that do nothave constant values propagated to them. For instance, referring to theillustrative drawings of FIG. F8, the exposers and collectors in thisportion of a design possibly could be removed by the remove collectorand exposer object process. The result would be a much-simplifiednetlist.

Polymorphic Objects

In accordance with an aspect of the present invention, Polymorphicobjects have been constructed that rely upon conditional branching usinga select object to selectively synthesize a behavior in any of multipleimplementations. Furthermore, polymorphic objects have been constructedin which the outcome of the conditional branching depends uponprocessing of one or more parameters through a control processimplemented by a constituent control object. Specifically, polymorphicobjects have been constructed which include or reference constituentobjects that can be used to implement the same behavior in multipledifferent ways depending upon one or more parameters. Moreover,polymorphic objects have been constructed in which the object itselfincludes or references select objects to achieve conditional branching.Such polymorphic objects have been constructed in which the objectitself includes or references constituent control objects to process oneor more parameters so as to produce one or more select values to controlthe outcome of the branching, and therefore, to control the selectivesynthesis.

Polymorphic objects in accordance with a present embodiment of theinvention present to a user the ability to specify a behavior at a veryhigh level of abstraction and to rely upon the synthesis process toselectively synthesize the actual way in which that behavior isimplemented. Basically, the synthesis process uses one or more selectobjects and one or more control objects built into (or referenced by) apolymorphic object to determine which implementation of a behavior toselect. Such select objects and control objects, in essence, operate ascompiler instructions built in to (or referenced by) the polymorphicobject. More specifically, parameters provided to the one or moreconstituent control objects during the synthesis process are processedas part of the synthesis process to determine which implementation toselect. Thus, by incorporating a polymorphic object into a design a useressentially automatically incorporates the synthesis (or compiler)instructions used to determine how to actually selectively synthesizethe object.

Polymorphic ADD Example

A present embodiment of the invention includes a polymorphic ADD object.The polymorphic ADD is used to select between equivalent behaviortopologies to perform a function, i.e., the ADD function. A presentembodiment of the polymorphic ADD can be used to select between a serialadd behavior topology and a parallel add behavior topology which aredescribed below. The polymorphic ADD object can drive a selectivesynthesis process in accordance with the present invention to includewithin a design database either a serial add object or a parallel addobject depending upon parameters tested in the course of the selectivesynthesis process. Each of these two different add objects (serial andparallel) represent the same function: they add together values providedto them. Thus, the polymorphic ADD permits the performance of the samefunction using different topology behaviors.

In object oriented programming terms, the polymorphic ADD object 200 canbe viewed as the ADD class. The serial add object and the parallel addobject can be viewed as two instances of the ADD class. The ADD object200 is at the top of an ADD behavior object hierarchy. The serial addobject and the parallel add object are child objects of the top-levelobject 200. The processes whereby the top-level ADD behavior object istransformed into either a serial add object or a parallel add object iscalled selective synthesis. The ADD class and its instances exist aslibrary objects accessible through a computer user interface. Libraryobjects are connected together with transports in order to create adesign diagram and to build a corresponding design database. In thepresent embodiment, the moniker, “ADD” as denotes the ADD class ofbehavior.

The ability to selectively synthesize one or another behavior topologycan be advantageous in trading of processing speed and process resourcesconsumed. For instance, a parallel add topology may process more quicklythan a serial add topology. However, a parallel add topology may consumefar more processing resources than a serial add topology. Thepolymorphic ADD object can be constructed with a constituent controlobject that causes a selective synthesis process to choose betweenparallel and serial add behavior topologies based on prescribedparameters so as to optimize the speed versus resources tradeoff.

Referring to the illustrative drawing of FIG. D1, there is shown atop-level polymorphic ADD object 200 that can be included within adesign diagram in accordance with a presently preferred embodiment ofthe invention. A corresponding top-level polymorphic ADD object isincluded within a design database when the polymorphic ADD object 200 isincluded within a design diagram. The design diagram is representativeof corresponding behavior objects in the design database. Thepolymorphic ADD object 200 includes five input nodes and two outputnodes. The five input nodes (from top to bottom) can be connected toreceive the information and have data set types described in thefollowing table. Polymorphic ADD Input Nodes Carry-in bit Value Avariant Value B variant Load bit Clock bit

The two output nodes (from top to bottom) can be connected to providethe information and have the data set type described in the followingtable. Polymorphic ADD Output Nodes Sum Value Variant Carry-out bitThe top-level polymorphic ADD object when inserted in a design databaseserves as a token used by the synthesis process to reference the nextlevel polymorphic ADD object located in the object library. The nextlevel polymorphic ADD object includes or references the constituentobjects combined to implement the polymorphic ADD object in an actualdesign database. During the synthesis process, the next levelpolymorphic ADD is referenced to selectively synthesize either theserial or the parallel add behavior topology. The following paragraphsdescribe the selective synthesis using a polymorphic ADD as an example.

Selective synthesis takes place during the synthesis process itself. Ina present embodiment of the invention, a precursor to the actualperformance of the synthesis process is the construction of a designdiagram in a graphical user interface environment. The construction ofthe design diagram causes the creation of a design database in whichbehavior objects corresponding to behavior objects in the design diagramare connected together in the same way as the corresponding designdiagram objects are interconnected with each other in the designdiagram. Moreover, the synthesis process of the present embodiment ofthe invention proceeds through a propagation of information from objectto object in the design. This propagation is achieved through the use oftransport objects whose role is to propagate information betweenobjects. Thus, before the polymorphic ADD object 200 can be used inselective synthesis, it is connected by transports to one or more otherobjects in a design database. Selective synthesis occurs whenappropriate information is propagated to the polymorphic ADD object soas to trigger the selection of either a serial add topology or aparallel add topology within the design (database and diagram).

Referring to the illustrative drawing of FIG. D2, there is shown thepolymorphic ADD object connected with transports that can cause thepropagation of information to and from the polymorphic ADD object duringthe synthesis process. It will be appreciated that the transports may beconnected to other behavior objects in the design, but these otherobjects are not shown so as to simplify the description of thepolymorphic ADD and selective synthesis. The point is that, duringsynthesis process, the transports interconnected with the polymorphicADD object 200 can propagate information to and from the object 200. Theinformation propagated to the polymorphic ADD object 200 triggers theselective synthesis resulting in selection of a serial add topology or aparallel add topology.

As shown in FIG. D2, transport 202 connects node 204 with the Carry-innode of object 200. Transport 206 interconnects node 208 with the ValueA node of the object 200. Transport 206 interconnects node 208 with theValue A node of the object 200. Transport 210 interconnects node 212with the Value B node of the object 200. Transport 214 interconnectsnode 216 with the Load node of the object 200. Transport 218interconnects node 220 with the Load node of the object 200. Transport222 interconnects node 224 with the Sum Value node of the object 200.Transport 226 interconnects node 228 with the Carry-out node of theobject 200.

Now, assume for the purposes of this example that the object 200 and thetransports connected to it are connected to other objects (not shown)and that the synthesis process is in progress. Further, assume thatinformation has been propagated from the other objects (not shown) tonodes 204, 208, 212, 216 and 220. Specifically, assume that these nodeshave the following data set types propagated to them. Node 204 has a bittype data set type propagated to it. Node 208 has a byte type data settype propagated to it. Node 212 has a byte type data set type propagatedto it. Node 216 has a bit type data set type propagated to it. Node 220has a bit type data set type propagated to it.

Assume that, at this point in the propagation process, the synthesisprocess finds that it has reached an object, object 200, with varianttype input nodes (Value A and Value B). The synthesis process cannotpropagate data set information from one node to another unless those twonodes possess the same data set type. Hence, data set propagation cannotcontinue from node 208 to the Value A node and from node 212 to theValue B node. The data set types of the Value A and the Value B nodesmust be brought into alignment with those of nodes 208 and 212 beforedata set propagation can continue. The manner in which the synthesisprocess brings the nodes into alignment is to reference the next levelpolymorphic ADD object shown in FIG. D3 so and to insert that objectinto the design database in place of the top-level ADD object 200. Wecall this flattening the hierarchy.

The illustrative drawing of FIG. D3 shows a next level polymorphic ADDbehavior object 230. Object 230 is both data set polymorphic and “otherparameter” polymorphic. In this example, the other parameter isinformation rate. However, it will be appreciated that the otherparameter can be any parameter that can be related to nodes in thedatabase, e.g., information rate, information rate pattern, data set,etc. It is data set polymorphic because it has variant input nodes. Itis information rate polymorphic because the it is resolvable into eithera serial add behavior object topology or a parallel add behavior objecttopology based upon the processing of information rate information by acomposite control object associated with the object 230. Data setpolymorphism is the subject of another section and shall not bediscussed in this section. Information rate polymorphism shall bediscussed in detail in the following paragraphs of this section.

The next level polymorphic ADD behavior object 230 includes a serial addbehavior object 232 and a parallel add behavior object 234. It will beappreciated that the polymorphic ADD object 230, the serial add behaviorobject 232 and the parallel add behavior object 234 all are logicalequivalents. That is, each achieves the same function. However, asbest-illustrated in FIGS. D9 and D10, the topologies of the serial addobject and the parallel add object are quite different. As explained indetail below, the synthesis process can use the polymorphic ADD object230 to select between a serial add topology 232 and a parallel addtopology 234 based upon one or more prescribed parameters. In thisexample, the parameter is information rate.

Referring to FIG. D3, each of the serial and parallel behavior objectsis variant type since each has a variant type on at least one node.Object 230 includes seven select objects 236, 238, 240, 242, 244, 246and 248. Each of the select objects is a variant select object sinceeach has a variant variable type on at least one node. Object 230includes comparator objects 250 and 252. Object 230 includes sourcenodes 254, 256, 258, 260, 262, 264, 266 and 268. Object 230 includessink nodes 270 and 272. Object 230 also includes numerous transportobjects that connect the other constituent objects as shown. Forinstance, transport 274 connects source node 254 with the carry-in inputnode of the serial add behavior object and the carry-in input node ofthe parallel add object 234. Similarly, for example the compositetransport object 276 connects the A>B output node of comparator 252 withthe select input nodes of each of (variant) select objects 236, 238,240, 242, 244 and 246. The composite transport object 278, for example,connects the source node 256 with the A Value input node of selectobject 236 and with the B Value input node of select object 240.Transport object 275 connects the output node of select object 236 tothe Value A input node of serial add object 232. Transport object 277connects the output node of select object 238 to the Value B input nodeof serial add object 232. Transport object 279 connects source node 258with the Value A input node of select object 238 and with the Value Binput node of select object 242. Transport object 281 connects theoutput node of select object 240 to the Value A input node of paralleladd object 234. Transport object 283 connects the output node of selectobject 242 to the Value B input node of parallel add object 234. Theconnections made by the other constituent transport objects can begleaned from the drawings.

The synthesis process inserts the polymorphic ADD behavioral object 230into the design in place of the top-level polymorphic ADD behaviorobject 200. From FIGS. D2 and D3, it will be appreciated that sourcenode 254 is connected to transport object 202. Source node 256 isconnected to transport object 206. Source node 258 is connected totransport object 210. Source node 260 is connected to transport object214. Source node 262 is connected to transport object 218. Sink node 270is connected to transport object 222. Sink node 272 is connected totransport object 228.

The next level polymorphic ADD behavior object is a composite object inthat it comprises other objects. These constituent objects cooperate toselectively synthesize either a serial add topology by causing selectionof serial add object 232 or a parallel add topology by causing selectionof parallel add object 234. The (variant) select objects 236, 238, 240,242, 244, and 246 are connected to transports so that that throughselective synthesis, they can provide alternative data paths. Onealternative realized through selective synthesis results in transportobjects that connect serial add object 232 with the source nodes 254,256, 258, 260 and 262 and with the sink nodes 270 and 272. Anotheralternative realized through selective synthesis results in transportobjects that connect parallel add object 234 with the source nodes 254,256, 258 260 and 262 and with the sink nodes 270 and 272. Thus, theselect objects 236, 238, 240, 242, 244, and 246 are employed toimplement a branching function during the selective synthesis process.

The dashed lines labeled 280 delineate a portion of the next levelpolymorphic ADD behavior object used during selective synthesis tocontrol the selection between the parallel and serial add objects 232and 234. In this example, constant type parameters are provided onsource nodes 264 and 266. The comparator 250, (variant) select object248, source node 268 and comparator 252 process the parameters. A bittype output is provided on the A>B node of comparator 252. The bit typeoutput is propagated by composite transport object 276 to the selectinputs of (variant) select objects 236, 238, 240, 242, 244, and 246.

The evolution of the polymorphic ADD behavior object 230 duringselective synthesis now will be described. At some point soon after thenext level polymorphic ADD object 230 has been inserted into the designby the synthesis process, data set propagation will occur. Referring toFIG. D2, assume that the data set type on nodes 204, 216 and 220 is bittype. Assume that the data set type on nodes 208 and 212 is byte type.In that case, at some intermediate juncture of the data set propagationprocess data set propagation will result in the data set type on sourcenodes 254, 260 and 262 and on the clock and load input nodes of theserial and parallel add objects 232 and 234 being bit type. At thatjuncture, data set propagation will result in the data set type onsource nodes 256 and 258 becoming byte type. At that juncture, data setpropagation will result in the type on source nodes 264 and 266 beingconstant type. At that juncture, data set propagation will result in thedata set type on Value A and Value B nodes of each of the (variant)select objects becoming byte type. The data set type on each of theselect input nodes of each of the (variant) select objects is bit type.The data set type on the source node 268 is and remains constant type.At that juncture, data set propagation will result in the data set typeon the Value A and Value B input nodes of the serial add and paralleladd objects 232 and 234 remaining variant type for the time being. Atthat juncture, data set propagation will result in the data set on theDout (Sum Value) and S (Sum value) output nodes of the serial andparallel add objects 232 and 234 remaining variant type for the timebeing. At that juncture, data set propagation will result in the dataset of the carry-out nodes of the serial and parallel add objects 232and 234 remaining bit type. The data set type on the output node ofcomparator 252 remains bit type. At that juncture, data set propagationwill result in the data set types on the sink nodes 270 and 272 remainsvariant type.

At or about the juncture of the propagate data process described above,the synthesis process will identify the (variant) select objects 236,238, 240 and 242 in the data propagation path. A select object is not“flattened” like other objects in a data propagation path by calling alower level object in an object library and inserting the lower levelobject into a design in place of a higher level object. Rather, a selectobject is resolved through a control process that results in a selectvalue that is provided to a select input node of the select object. Inthis example, the control process is implemented by synthesis processusing the objects within dashed lines 280. Basically, the objects withindashed lines 280 collectively function as a control object that controlsthe selection of which add object 232 or 234 to connect and which addobject 232 or 234 to leave unconnected. In essence, the collectivecontrol object 280 instructs the synthesis process (or compiler) how toresolve the alternative possible transport object connections describedabove.

In this example, a select value is propagated to each of the selectobjects via transport object 276. The select value determines which ofthe alternative connections will be created using the process (oralgorithm) associated with the select objects. The select value must bederived. In this example, the select value is derived through a controlprocess in which the information rates of the source nodes 256 and 258are parameters. Briefly stated, the control process in this examplefirst identifies the larger of the information rate on source nodes 256and 258. The control process then compares the larger information ratewith a predetermined information rate on source node 268. The comparisonresults in a constant value that is propagated to transport object 276and that also is propagated to the select input nodes of each of the(variant) select objects. Once this value has been provide, an algorithmof the general type described above, can be used by the synthesisprocess to achieve one or the other of the alternative connectionsdescribed above so as to select either the serial or the parallel addobject 232 or 234.

In this example, the synthesis process uses a Propagate Constantsprocess to calculate or to otherwise determine the select input value tobe propagated on transport object 276 based upon the information rateson source nodes 264 and 266. During the Propagate Constants process, aconstant value that has been propagated to an object is processed inaccordance with the behavior of the object so as to compute a resultingvalue. The resulting value then can be propagated to another object tobe processed in accordance with its behavior, etc.

More specifically, in this example, selective synthesis depends uponinformation rate of the data on source nodes 256 and 258. Source node264 receives as its input a constant value, namely the information ratevalue on source node 256. Source node 266 receives as its input aconstant value, namely the information rate on source node 258. Pursuantto the Propagate Constants process, these two values are propagated viatransport objects 284 and 286 to the input nodes of comparator 250. Inaccordance with the behavior of comparator object 250, if theinformation rate on source nodes 256, 264 is less than the informationrate on source nodes 258, 266 then the value propagated to transportobject 282 is logical 1. Otherwise, the value propagated to transportobject 282 is logical 0. Pursuant to the Propagate Constants process,the information rate values on source nodes 264 and 266 also arepropagated via transport objects 288 and 290 to the data A input nodeand to the data B input node of the (variant) select object 248. Theconstant value propagated to transport object 282 is propagated to theselect input node of select object 248. If the value propagated to theselect input node is logical 1, then, in accordance with the selectobject algorithm associated with the select object 248, a transportobject (not shown) is inserted into the design so as to connect thesource node 266 to the data A input node of comparator 252 via transportobject 292. On the other hand, if the value propagated to the selectinput node is logical 0 then, in accordance with the, a transport object(not shown) is inserted into the design so as to connect the source node264 to the data A input node of comparator 252 via transport object 292.Thus, the larger of the information rates on source node 256 and sourcenode 258 is propagated to the Value A input node of comparator 252. Aconstant value is provided on source node 268. In this example, theconstant value on source node 268 also represents an information rate.Pursuant to the Propagate Constants process, the constant value on node268 is propagated to the data B input node via transport object 294.Pursuant to the Propagate Constants process, the comparator 252 comparesthe information rate value on data A input node with the informationrate value on its data B input node. If the information rate on the dataA node is greater than the information rate on the data B input nodethen the output on the A>B node is logical 1. Otherwise, the output onA>B is logical 0.

Referring to the illustrative drawing of FIG. D4 there is shown afurther evolution of the design as the selective synthesis processprogresses through the polymorphic ADD object 230. It will beappreciated that the synthesis process actually involves multiplerecursive descent algorithms that operate roughly in parallel andsomewhat independently of each other. In addition to the data setpropagation algorithm, the flatten algorithm and the propagate constantsalgorithm, there is a sourceless and sinkless removal algorithm thatremoves from the design (trims away) objects that have source or sinknodes that are not connected.

FIG. D4 shows an intermediate state of object 230 in the course of thesynthesis process after comparator 250 has finished its comparisonduring the constant propagation process and after resolution of theselect object 248 has caused an addition of a transport object 293. Theadded transport object 293 connects the source node 264 with the data Anode of comparator 252. Also, the resolution of select object 248 leavestransport object 290 unconnected and, therefore, also leaves source node266 unconnected. In FIG. D4, the sourceless and sinkless (trimming)algorithm has removed from object 230, source node 266, comparator 250,variant select 248 and transport objects 286, 290 and 282 because theresolution of select object 248 leaves source node 266 unconnected.

FIG. D5 shows another intermediate state of object 230 in the course ofthe synthesis process after the comparator 252 has finished itscomparison during the constant propagation process and after thesinkless and sourceless (trimming) algorithm has processed some more.Assume that in this example, the information rate on source node 264 isgreater than the information rate on source node 266 (comparison bycomparator 250). Also, assume that the information rate on source node264 is greater than the information rate represented by the constantvalue on source node 268 (comparison by comparator 252). With theseassumptions, pursuant to the constant propagation process, thecomparator 252 produces a logical 1 value on its A>B node. In FIG. D5,the sourceless and sinkless (trimming) algorithm has removed from object230 source nodes 264 and 268, transport objects 288, 293, 294 and 292,and comparator 252 because source nodes 264 and 268 are unconnected.Since the value produced by the comparator 252 is logical 1, a logical 1value is provided on a source node of transport 276 after the removal ofthe comparator 252 by the sourceless and sinkless (trimming) algorithm.

FIG. D6 shows another intermediate state of object 230 in the course ofthe synthesis process after the constant propagation process hasprocessed some more and after the sinkless and sourceless (trimming)algorithm has processed some more. The propagate constants algorithm haspropagated the logical value 1 via transport object 276 (which has beenremoved in FIG. D6) to the select input node of each of the (variant)select objects 236, 238, 240, 242, 244 and 246. With the propagation ofthe logical 1 value at the select input node of the select objects, theselect objects now have the information necessary on each input for thesynthesis process to proceed with resolution of the select objects.Specifically, each of the select objects has a value propagated to itsselect input node.

Thus, in FIG. D6, the synthesis process has run a branching algorithmresponsive to the (select) value (logical 1 in this example) produced bythe control process (implemented with the objects in dashed lines 280 inFIG. D3 in this example). In accordance with a branching algorithmemployed in this example, a logical 1 select value propagated to theselect input node of a select object causes the creation of a transportobject between the Value B input node and the output node. The value Ainput node of the select object is left unconnected. Referring to FIG.D6, the branching algorithm has resulted in the addition of a newtransport object 296 to the design to connect transport objects 278 and281. Also, the branching algorithm has resulted in the addition of a newtransport object 298 to the design to connect transport objects 279 and283. The branching algorithm has left transport object 278 unconnectedto transport object 275. Also, the branching algorithm has lefttransport object 279 unconnected to transport object 277.

In a present embodiment of the invention, the synthesis processrecognizes that a select object is used to implement branching of thesynthesis process itself. In a current embodiment, the synthesis processdoes not attempt to “flatten” the select object to discern any nextlevel behavior object associated with it. The role of the select objectis to provide a branching function to the synthesis process, not toreference a behavior topology. Once a select object have performed itsbranching function, the select object is no longer required as part ofthe design and can be removed.

Referring again to FIG. D6, The branching algorithm has been run foreach of the select objects 236, 238, 240, 242, 244 and 246. Thebranching algorithm result for select object 236 is that transportobject 278 which is connected to the Value A input node is leftunconnected to transport object 275 which is connected to the outputnode of select object 236. The branching algorithm result for selectobject 238 is that transport object 279 which is connected to the ValueA input node is left unconnected to transport object 277 which isconnected to the output node of select object 238. The branchingalgorithm result for select object 240 (shown in FIG. D3) is that a newtransport object 296 is added to the design that connects transportobject 278 and transport object 281. The branching algorithm result forselect object 242 (shown in FIG. D3) is that a new transport object 298is added to the design that connects transport object 279 and transportobject 283. The branching algorithm result for select object 244 (shownin FIG. D3) is that a new transport object 300 is added to the designthat connects transport object 291 and transport object 293. A furtherbranching algorithm result for the select object 244 is that transportobject 285 which is connected to the Value A input node is leftunconnected to transport object 293 which is connected to the outputnode of select object 244. The branching algorithm result for selectobject 246 (shown in FIG. D3) is that a new transport object 302 isadded to the design that connects transport object 289 and transportobject 295. A further branching algorithm result for the select object246 is that transport object 287 which is connected to the Value A inputnode is left unconnected to transport object 295 which is connected tothe output node of select object 246.

In FIG. D6, select objects 240, 242, 244 and 246 are not shown becausethey have been removed from the design. The synthesis process has causedthem to be replaced in the design (diagram and database) by thetransport objects (composite transports in this case) that result fromthe branching algorithm. Select objects 236 and 238 are shown in FIG.D6. Note the absence of transport objects connecting an input node to anoutput node in the select objects 236 and 238. The synthesis processinterprets an absence of a transport connection as an unconnected sourceand unconnected sink. The sinkless and sourceless (trimming) processcauses the removal of dangling objects as described below. In FIG. D6,the sourceless and sinkless (trimming) algorithm already has caused theremoval of transport object 276 since the select value (logical 1 inthis example) already has been propagated to the select input nodes ofthe select objects.

FIG. D7 shows another intermediate state of object 230 in the course ofthe synthesis process after the sinkless and sourceless (trimming)algorithm has processed some more. Briefly, the sinkless portion of thesinkless and sourceless algorithm works backwards through the design.That it is it processes the design in a direction opposite to thedirection of information flow in the design. Basically, it seeks outsink nodes that are not connected, and it removes the objets that haveno connected sink nodes. In other words, if an object has no sink nodeconnected to another downstream (in the normal propagation directionthrough a design) object in the design, then the object is removed. Thetheory behind this sinkless removal process is that if an object has nosink node that contributes to downstream processing then the objet issuperfluous and can be removed. Pursuant to the sinkless removalprocess, the serial add object 232 has been removed since it hasdangling sinks, transports objects 285 and 287. Further, pursuant to thesinkless removal process, the transport objects 285,287, 275, 277, 299and 301 connected to the removed serial add object 232 also have beenremoved. Note that the removal of transport objects 299 and 301 leavessource nodes 260 and 262 dangling.

FIG. D8 shows another intermediate state in the evolution of object 230in the course of the synthesis process. The sinkless and sourceless(trimming) algorithm has processed some more. The compress transportalgorithm has removed unnecessary junctions in the transport objects ofFIG. D7.

Specifically, the sinkless algorithm portion has removed sources 260 and262 since they do not connect with any downstream object. Also, thetransport object branches of composite transports 278 and 279 that hadbeen connected to select objects 236 and 238 had been removed since theyhad been left with dangling sinks (see FIG. D7). Note how the sinklessalgorithm portion has progressed in a direction that can be described asupstream or opposite to the direction of information (e.g., data set)propagation in the design. First, the serial add object 232 and all(transport) objects connected to it were (see FIGS. D6 and D7) removedsince the serial add object 232 was not connected to any downstreamobject. Next, the sinkless algorithm portion moved upstream in thedesign to the two source nodes 260 and 262 which have been left sinklessdue to the removal of the serial add object and its transports. Thesesource nodes 260 and 262 are removed from the design because they havebecome sinkless due to the progression of the sinkless algorithm itself.Note also the recursive nature of the sinkless algorithm portion. Itsearches for sinkless objects (e.g., serial add object 232) and removesthem. Then it recourses to seek objects (e.g., source nodes 260 and 262)that may have become sinkless due to the earlier removal of othersinkless objects.

Moreover in FIG. D8, transport objects 304, 306, 308, 310 and 312 havebeen created in the design to replace the various composite transportobjects that had existed before. For instance, transport object 306replaces the composite transport object comprising transport objects278, 296 and 281 (see FIG. D7). It will be appreciated that theconsolidation of composite transport objects into one (or more) simplerobjects by the compress transports process removes unnecessary andperhaps redundant transport objects from the design.

Recall that the source nodes 256 and 258 both have byte type data setson them. The source node 254 has a bit type data set. In a presentlypreferred embodiment of the invention, a parallel add behavior object234 has variant type Value A and Value B input nodes and a bit typeCarry-in node. At the stage of the synthesis process illustrated in FIG.D8, the synthesis process calls the propagate data set process whichcauses the byte type data set to propagate from source nodes 256 and 258to the Value A and Value B nodes of the serial add object 234. It willbe appreciated that a variant type node can have a data set of any othertype propagated to it. After the propagation of the byte type data setfrom the source nodes 256 and 258, the Value A and Value B nodes of theserial add object 234 also have a byte type data set on them.

The parallel add object 234 of FIG. D8 is a top-level parallel addobject. As such, the synthesis process regards it as a token used toreference a next level parallel add object 310 shown in FIG. D9.Specifically, upon completion of the propagation of data sets to theinput nodes of the parallel add object 234, the synthesis process callsthe flatten process. (TRUE?) The next level parallel add object 310illustrated in FIG. D9 is inserted into the design in place of the toplevel parallel add object 234. The next level parallel add object 310 isa self-referential object that includes: source nodes 318, 320, and 322,sink nodes 324 and 326, variant exposers 312 and 314, a variant data setcollector 316, parallel add objects 328 and 330 (self-references) andvarious transport objects. The synthesis process employs a recursiveflatten process described elsewhere in this disclosure to resolve theparallel add object 310.

For the sake of completeness, FIG. D10 provides an illustration of anext level serial add object 330. The serial add object 232 of FIG. D3is a top-level serial add object. As such, the synthesis process regardsit as a token used to reference a next level serial add object 330 shownin FIG. D10. If the propagate constants process had resulted inproduction of a logical 0 value by comparator 252, then the synthesisprocess would have resolved the polymorphic ADD object 230 down to thetop-level serial add object 232 and its associated transport objects,sources and sinks. The top-level serial add object 232 references thenext level object 330 of FIG. D10. We will not go into depth concerningthe next level serial add object 310. We note, however, that it includesvariant shift-in objects 332 and 334, a top-level parallel add object336, a variant multiplexer 338, an assign object 340 (memory), a variantshift-out object 342 and a variant type object 344. As explained above,the synthesis uses a recursive flatten process described elsewhere inthis disclosure to resolve the serial add object 330.

One advantage of behavior objects in general is that it facilitatesoptimized synthesis in which tradeoffs are made between differentparameters. For example, in system design, the tradeoff between hardwareresources and speed often is a factor in deciding what topology to useto realize a desired behavior. Polymorphic behavior objects can be usedto optimize the synthesis process based upon a tradeoff betweendifferent parameters such as hardware resources and speed. For instance,using the polymorphic ADD object behavior again as just one example, oneillustrative hardware substrate or platform in which an add behavior canbe implemented is a Vertex field programmable gate array (FPGA),produced by Xilinx, Inc. of San Jose, Calif. By way of comparison, a 128bit wide add can be implemented as either a serial add or as a paralleladd. It is believed that a 128 bit wide serial add topology wouldrequire approximately five combinational logic blocks (CLBs) of the FPGAand would require one clock cycle per bit to perform the add (i.e., 128clock cycles). In contrast, it is believed that a 128 bit wide paralleladd topology would require approximately one hundred and twenty-eightCLBs and would require only one clock cycle for all one hundred andtwenty-eight bits. The serial add topology requires fewer hardwareresources but is slower. The parallel add topology requires morehardware resources but is faster. Thus, there is an obvious hardwareresources versus speed tradeoff. A synthesis process in accordance witha present embodiment of the invention can employ a polymorphic objectbehavior (the add behavior is just one example) to automatically andselectively synthesize object behavior topologies based upon parameterssuch as information rate, data set type or information rate pattern, forexample.

Code reuse is another advantage of polymorphic behavior objects. Forinstance, a given polymorphic behavior object can be used to achieve thesame logical function (e.g., add, multiply, shift, divide, cast, etc.)in different designs. A synthesis process in accordance with the presentinvention can selectively synthesize logically equivalent objects ineach design to achieve the desired function. However, the topologies ofthe logically equivalent objects may differ from one design to the next.The given polymorphic object includes (or references) the controls usedby the synthesis process to determine what topology to selectivelysynthesize in any given design to achieve the equivalent functionconsistent with the parameters specified for that design.

Example of Propagate and Flatten Processes Used to Resolve Data SetPolymorphic Variant Object

This section provides data set polymorphic variant behavior object. Bydata set polymorphic it is meant that the resolution of the object inthe course of the synthesis process is data set dependent. Theresolution is different for different data sets. Although the variantinvert behavior object is the focus of this example, the principlesexplained in this section apply to other data set polymorphic variantbehavior objects as well. This example will show a behavior object thateffects a pattern of behavior that references another object. Inparticular, the variant form of the invert behavior object effects apattern of behavior that is references another object. Morespecifically, the variant form of the invert behavior object effects apattern of behavior that is self-referential. That is, the behaviordefined for a variant invert object references the variant invert objectitself.

This section also will illustrate that the propagate data process andthe flatten algorithm are mutually dependent. As one variant invertobject after another is instantiated due to the flatten process, thedata set propagation process responds by propagating data sets from apreviously instantiated variant invert object to a more recentlyinstantiated variant invert object. Conversely, as one instantiatedvariant invert object after another has data sets propagated to it dueto the propagate data process, the flatten algorithm responds byinstantiating another invert object each time a data set has beenpropagated to all input nodes of an invert object referenced in apreviously instantiated variant invert object.

This section also demonstrates the use of the propagate data set and theflatten functions to “solve” the hardware needed to solve a logicalproblem for a given data set. The invert function is a fundamental logicfunction. It converts a logical 1 to a logical 0. Conversely, itconverts a logical 0 to a logical 1. This section demonstrates themanner in which the recursive flatten and propagate data processescooperate to build a composite structure to implement the invertfunction for a given data set. At the end of the propagate data andflatten processes, the resulting structure comprises basic objects thatcan be used to implement the invert function for a given data set.

FIG. F1 is an illustrative drawing of a portion of an object librarypertaining to the invert equivalent function. This portion of the objectlibrary includes a top-level invert object 500, a variant invert object502 and an atomic invert object 504. The top-level invert object 500references both the variant invert object 502 and the atomic invertobject 504.

FIG. F2 shows a representation of the top-level invert function 500. Itincludes a data set input node 506 and a data set output node 508. Thetop-level invert object 500 is variant type. It can be inserted into adesign to effect the invert function.

FIG. F3 shows an illustrative diagram representing the variant invertobject 502. It includes a data set exposer object 510 and a data setcollector object 512. It also includes two variant invert objects 500.The input node of the exposer 510 is variant type. Abstract transportobject 514 connects one output node of the exposer object 510 to aninput node of one variant inverter object 500. Abstract transport object516 connects another output node of the exposer object 510 to an inputnode of another variant inverter object 500. Abstract transport object520 connects another output node of one invert object 500 to anotherinput node of the collector object 512. All nodes of the variant object502 are variant type.

FIG. F4 shows an illustrative diagram of the atomic invert object. Itincludes an atomic invert object. Transport 524 interconnects anode ofsource object 526 to an input of the atomic invert object. Transport 528interconnects a node of sink object 530 to an output of the atomicinvert object 522. All nodes of the atomic object 522 are bit type.

FIGS. F5-F8 show illustrative diagrams of the evolution of an invertobject in a design in response to the propagation of a nibble (4-bit)data set to its input node. FIG. 5 shows a portion of a design in whicha top-level or parent-level invert object 500 has been inserted. Theinvert object 500 includes a input node 506 and an output node 508. Inthis example, for the sake of simplicity, only a few other objects in anoverall design are shown. Specifically, transport object 532 connects asource 534 to the input node 506, and transport object 536 connects theoutput node 508 to sink object 538. Transport object 532 is disposedupstream in the design from top-level invert object 500. Transportobject 536 is disposed downstream in the design from top-level invertobject 500. For completeness, the nodes 540 and 542 of transport object532 are shown, and the nodes 544 and 546 of transport object 536 areshown. Also, the node 548 of source object 534 is shown, and the node550 of sink object 538 is shown.

Assume in this example, that in the course of the synthesis process thepropagate data sets process propagates a nibble type data set (i.e.,4-bits) to the input node 506 of the invert object 500 of FIG. F5. Atthis juncture of the synthesis process, the synthesis process willdetermine that all nodes of the invert object 500 have data sets definedfor (propagated to) them. It also will determine that the invert object500 is a variant type object. The flatten algorithm uses the invertobject 500 to find other equivalent functions that are candidates to beinserted into the design in place of object 500.

More particularly, in a present embodiment of the invention, a name isassociated with the invert object 500. Specifically, the name “invert.”The flatten algorithm uses this name to find the portion of the objectlibrary shown in FIG. F1. The invert object 500 references the variantinvert object 502 and the atomic invert object 504. Note that in acurrent embodiment, object naming is used to denote equivalency offunction. Each of these objects is an equivalent function of the other.Therefore, each shares the invert name.

The flatten algorithm determines whether there is an explicit matchbetween an invert object in library portion of FIG. F1 and the data setpropagation status of the invert object 500 in FIG. F5. That is, theflatten algorithm determines whether there is an invert object in theobject library with an explicit nibble type data set on its input node.There is not. Thus, the flatten algorithm selects the variant invertobject 502 from the library for insertion into the design in place ofobject 500.

FIG. F6 shows the resulting insertion of the variant invert object 502into the design. An input node of variant exposer object 510 isconnected to a node 542 of transport 532. An output node of collectorobject 512 is connected to a node 544 of transport object 536. Note thatfrom the perspective of other objects in the design, the data setpropagation pattern is unchanged following insertion of the variantinvert object into FIG. F6. That is, in FIGS. F5 and F6, before andafter the insertion, transport object 532 propagated a 4-bit type dataset to a single input node of the object connected to it. Also, in FIGS.F5 and F6, before and after the insertion, transport object 538 wasconnected to receive a data set propagated to it from another object.Thus, the pattern of processing effected by the top-level invert object500 in FIG. F5 and the variant invert object in FIG. F6 is unchangedfrom the perspective of other objects in the design.

At this juncture of the synthesis process, the variant invert object 502has been inserted in place of invert object 500, and the nibble data sethas been propagated to the input node of the data set exposer object 510of the variant invert object 502. The flatten algorithm again searchesthe object library, this time for an explicit match to the data setexposer object 510 of FIG. F6. Assume that in this example the objectlibrary has an explicit match to a data set exposer object (not shown)with a nibble (4-bit) input node and two Dbit (2-bit) output nodes. Theflatten algorithm inserts that explicitly matching exposer object intothe design in place of the variant exposer object 510. For the sake ofsimplicity, this data set exposer insertion is not shown in FIG. F6. Theinsertion of another data set exposer object is indicated in FIGS. F6 F7by labeling the inserted exposer object with reference numeral 510′.

At this juncture of the synthesis process, the propagate data processpropagates the 4-bit data set type through data set exposer object 510′which outputs a 2-bit type data set type on each of its two outputnodes. The two respective 2-bit data set types are propagated torespective transport objects 514′ and 516′ and then to the respectiveinput nodes of the two top-level objects 500. The respective transportobjects are labeled 514′ and 516′ to indicate that the abstracttransport objects 514 and 516 of the variant invert object 502 have beenresolved, through the propagate data sets process, to 2-bit data settype transport objects. Still referring to FIG. F6, at this stage of thesynthesis process, the propagate data sets process has propagated 2-bitdata sets to the input nodes of the two invert objects 500 of FIG. F6.

It will be appreciated from the following discussion that the embeddingof a variant object inside another object creates a conditional branchin the process of synthesizing a design that includes the embeddingobject. Specifically, note the implications of the self-referentialnature of the variant invert object 502. More generally, note theimplications of a reference within one object to another variant object(whether the reference is self-referential or not). In particular,variant invert object 502 in FIGS. F3 and F6 references the top-levelvariant invert object 500 of FIG. F2. As shown in FIG. F1, the top-levelobject 500 in turn references the variant invert object 502. Moreover,as will be appreciated from the discussion of FIG. F7, thisself-reference creates an opportunity for the flatten process to selectamong the multiple invert objects 502 and 504 the object library portionof FIG. F1. Thus, references within one object (variant invert object502 in this case) to another variant object (top-level invert object 500in this case) create an opportunity for the synthesis process to branchamong different synthesis alternatives (between the insertion of object502 or 504 into the design in this case). In effect, this is aconditional branch opportunity. One condition of the branch is the typeof data set propagated to the one or more (one in this case) input nodesof the referenced variant object (object 500 in this case) embedded inanother object (object 502 in this case). Another condition of thebranch is the nature of the equivalent function objects in the objectlibrary referenced by the referenced object (object 500 in this case).

At this stage of the synthesis process in which 2-bit type data sets arepropagated to the respective input node of the two variant invertobjects 500, the flatten algorithm again references the object libraryportion illustrated in FIG. F1. This time it searches for an explicitmatch between an object with the invert equivalent function behavior andan explicit 2-bit type data set on its input node. There is no match.Therefore, as shown in FIG. F7, the flatten algorithm causes arespective instance of the variant invert object 502 to be inserted intothe design in place of each in stance of the top-level invert object 500in FIG. F6. Thus, at this juncture of the synthesis process, twoinstances of the variant invert object 502 are located in the designbetween transport objects 532 and 536.

It will be appreciated from FIG. F7 that from the perspective of otherobjects in the design, the data set propagation pattern is unchangedfollowing insertion of the two instances of the variant invert object502 into the design of FIG. F6. That is, in FIGS. F6 and F7, before andafter the insertion, transport object 532 is connected to propagate a4-bit type data set to a single input node of the object connected toit. Also, in FIGS. F6 and F7, before and after the insertions, transportobject 538 is connected to receive a data set propagated to it fromanother object. Furthermore, in FIGS. F6 and F7, before and after theinsertions, each of transport objects 514′ and 516′ propagated a 2-bittype data set to respective objects connected to them. Thus, the patternof processing effected by the top-level invert object 500 in FIG. F5 andthe variant invert object in FIG. F6 and the two variant invert objectsof FIG. F7 is unchanged from the perspective of other objects in thedesign.

The flatten process operates in the manner described above to insert twoinstances of an explicit data set exposer object 510″ shown in FIG. F7in place of the two instances of the variant data set exposer object 510of the variant invert object of FIG. F3. Next, the data sets propagationprocess operates to respectively propagate the 2-bit type data set oneach of the respective output nodes of the two data set exposers 510″.The two instances of data set exposer 510″ provide on their respectiveoutput nodes respective 1-bit type data sets. The propagate data setsprocess propagates the four respective 1-bit type data sets to therespective transport objects 514″ and 516″. It will be appreciated thatabstract transports 514 and 516 of the respective instances of thevariant invert object 502 have been transformed into transport objects514″ and 516″ suited to propagate a 1-bit type data set. Thistransformation is achieved by the cooperation of the propagate data setsand flatten processes.

Note that at this juncture of the synthesis process, the design includesthree instances of abstract transport object 518 and three instances ofabstract transport object 520. It also includes three instances ofvariant collector object 512. These objects will not be resolved intoexplicit type objects until after the instances of the top-level invertobject 500 have been resolved.

Next, the propagate data sets process propagates the four respective1-bit type data sets to the four respective instances of the top-levelinvert object 500 shown in FIG. F7. Since a 1-byte type data set hasbeen propagated to the input nodes of each of the four instances of thetop-level invert object 500, the flatten algorithm searches for anequivalent function object with an explicit 1-bit type data set on itsinput node. Specifically, the flatten algorithm searches the objectlibrary portion illustrated in FIG. F1 for a match. This time there isan explicit match. The atomic invert object matches. It has a 1-bit typedata set on its input node, and it has an equivalent function.Therefore, as shown in FIG. F8, the atomic invert object 504 is insertedinto the design in place of the top-level invert function 500.

It will be appreciated that this time the synthesis process has branchedto select an explicit data set type object (i.e., atomic invert object504) rather than a variant type object (i.e., variant invert object502). The selected explicit 1-bit type data set atomic invert objectshares an equivalent function with the top-level invert object asindicated by its association with the top-level invert object 500indicated in FIG. F1. It also has an explicit type data set (1-bit type)that matches the data set type propagated to the top-level invert objectreferenced in the design at this stage of the synthesis process.

At this juncture of the synthesis process, the top-level invert object500 of FIG. F5 has been resolved into the four atomic invert objects ofFIG. F8. Referring to FIGS. F7 and F8, the propagate data sets processrespectively propagates the 1-bit type data set through the fourrespective atomic invert objects 504. The propagate data sets andflatten processes cooperate to respectively transform the fourrespective abstract transports 518 (two of them) and 520 (two of them),shown in FIG. F7, connected to the output nodes of the four respectivetop-level invert objects 500 into four respective transport objects 518″(two of them) and 520″ (two of them), shown in FIG. F8, connected to theoutput nodes of four respective atomic invert objects 504. Each oftransport objects 518″ and 520″ is suited to transport a 1-bit type dataset. Similarly, the propagate data process and flatten process cooperateto respectively transform the respective two variant data set collectorobjects 512 in FIG. F7 into two respective explicit data set collectorobjects 512″ in FIG. F8 suited to receive a 1-bit type data set on eachof its two input nodes. Similarly, respective transport objects 518 and520 connected between variant data set collector objects in FIG. F7 aretransformed into respective transport objects 518′ and 520′ in FIG. F8suited to transport 2-bit type data set. Finally, variant data setcollector object 512 connected to transport object 536 in FIG. F7 isresolved into an explicit data set collector objects 512′ in FIG. F8suited to receive a 2-bit type data set on each of its two input nodes.

Thus, the variant type top-level invert object 500 of FIG. F5 has beenresolved into four atomic invert objects 504 in FIG. F8.

Note that the pattern of processing from the perspective of otherobjects in the design (transport objects 532 and 536 in this example)remains unchanged. This is the case even though each atomic invertobject 504 in FIG. F8 can receive and propagate only a 1-bit type dataset, whereas a 4-bit type data set is propagated to the top-levelvariant object in FIG. F5. That is, transport object 532 propagates a4-bit type data set to a single node in FIG. F5 and in FIG. F8.Transport object 536 still is connected to a single node in FIG. F5 andin FIG. F8.

Also note that the resolution process involved several levels ofconditional branching at different stages of the data set propagationand flatten processes. The conditional branching was dependent upon thenature of the data set propagated to a referenced variant object atthese stages. The nature of the propagated data sets changed (evolved)from one stage to the next. Thus, the variant invert object 502 and thetop-level invert object 500 that references it (and that it referencesin turn) are data set polymorphic. Their resolution during at differentstages of the synthesis process is dependent upon the nature of the dataset(s) propagated at such different stages.

Also note that a network of explicit transport objects in FIG. F8 hasbeen automatically created or evolved into existence so as to match thedata set propagated by transport object 532 to the input node 506 of thetop-level variant invert object 500 of FIG. F5. More specifically, thesynthesis process creates transport objects to match data setrequirements that can be specified (or changed) after a design has beenconstructed. That is, a design is constructed using variant objects.Later, one or more data sets are propagated through the design toresolve the variant objects. During the resolution process, transportobjects are created (or evolved) to match the resolved variant objects.

Computational Polymorphic Objects

In one aspect, the present invention provides a computationalpolymorphic object. A computational polymorphic object is one that canbe synthesized in accordance with one or more computations. Moreparticularly, a computational polymorphic object includes a controlportion that performs a computation using one or more parameters, whichmay have been generated or propagated to it during a synthesis process,to produce control information that directs the synthesis of thepolymorphic object.

FIGS. P1-P7 shall be used to provide a hypothetical example of such acomputational polymorphic object. The hypothetical polymorphic objectperforms an add behavior. The add behavior adds data sets propagated toinput A to data sets propagated to input B. The polymorphism of this addobject permits the object to be synthesized differently to achievevarying degrees of parallelism depending upon data set type propagatedto input nodes A and B, information rates propagated to input nodes Aand B and information rate capacity of the target hardware system of thesynthesis process.

Referring to FIGS. P1 and P2, there are shown examples of a one bitserial add and a two bit serial add. The purpose of the drawings ofFIGS. P1 and P2 is to illustrate different degrees of parallelism in aserial add function.

FIG. P3 shows a hypothetical computational polymorphic add object 800.Object 800 includes a variant data set type parallel add object 802,shift-in objects 804 and 806 and a shift-out object 808. The shift-inobjects 804 and 806 and the shift-out object 808 respectively shift inand shift out a number of bits of data at a time that is dependent upondata set type. The object 800 also includes a control portion 810 shownwithin dashed lines. The function of objects 812 and 814 of controlportion 810 are the same as those of corresponding objects shown in FIG.D3. The divider object 816 performs a computational function resultingin a constant value. Specifically, it divides the selected informationrate provided by object 814 into the maximum information rate of thesystem, a constant value provided by source node 819. Selector object818 produces a data set type signal based upon the result of the dividecomputation. Note that multiple data set signals are provided on sourcenodes 822 as possible data set type selections. The selected data settype is provided to the type input nodes of the shift-in objects 804 and806 to determine how many bits at a time they shall shift in to the addobject 802. The selected data set type also is provided to the typeinput node of the shift-out objects 808 to determine how many bits at atime it shall shift out.

Inside each of the respective Shift-in objects 804 and 806 and insidethe shift-out object 808 is a shift-by-type object that is part of anobject hierarchy illustrated in FIGS. P4-P7. FIG. P4 illustrates thetopology of a variant type data set shift-by-type object. FIG. P5 showsa topology of a terminal leaf of the variant shift-by-type object. Itincludes an RCR (rotate through carry right) object, also known asarithmetic shift right. FIG. P6 illustrates the topology of a varianttype data set RCR object. FIG. P7 illustrates the topology of a terminalleaf RCR object.

Of course, the overall synthesis of object 800 involves much more thatwill be understood by those skilled in the art from explanations inother sections of this disclosure. Nevertheless, it will be appreciatedthat during the synthesis process in accordance with the invention, ashift-by-type object will be synthesized in accordance with theselection by selector 818. Of course the selector 818 selects based upona computation by object 816. Thus, the resolution of add object 800depends upon a computation performed by a control portion 810 of the addobject itself. The resolution of the input and output shift-by-typeobjects, in turn, influences the overall synthesis of the polymorphicadd object hypothetical computatorial.

Information Rate Pattern Polymorphism

The amount of buffering that is required between two components of asystem may depend on the information rate pattern and the comparativeability of the two components to operate at different information rates.There are numerous approaches to categorizing information rate patters.Here are a few examples: continuous, block continuous, block scaling,variable, variable scaling, complex (FFT or DCT) and indeterminate.Thus, information rate parameter can be an important parameter for usein a synthesis process. For instance, it can be important in decidingthe depth and width of a FIFO circuit. It will be appreciated thatinformation rate pattern is available as a synthesis parameter in acurrent embodiment of the invention.

Underloading

There have been shortcomings in object oriented programming techniquesthat impact the ability to modify an already complex class objecthierarchy. Specifically, as an object class hierarchy becomes morecomplex, it becomes more difficult to add additional levels ofabstraction to the hierarchy. Basically, the need to maintainconsistency with objects previously built into the hierarchy limits theability to alter abstractions at higher levels in the hierarchy.

Variant objects in accordance with the present invention create theability to more easily add new abstraction to even the most complexobject hierarchies. Basically, a new variant object easily can be added“under” a higher level object. At synthesis time, the synthesis processmay select the new variant object or not depending upon parameterspropagated or generated or otherwise imposed during the synthesisprocess. There is not a need to expend as much effort to ensureconsistency with the prior hierarchy. The synthesis process eitherselects the new variant object or it does not. Other objects are notsignificantly impacted. The ability to “underload” a hierarchy in thismanner is believed to make programming more efficient by promoting easeof code reuse in a variety of different behavioral descriptions andsystem designs.

Computer Program and Data Structure Implementation Encoded in ComputerReadable Media

It will be appreciated that computer program processes implement thevarious synthesis threads and other synthesis processes describedthroughout this document including calculations performed usingattributer calculator information. Moreover, it will be appreciated thatthe various threads and processes are implemented with computer programsstored in computer readable media. Furthermore the basic object classhierarchy and the various composite behavior objects and atomic objectsincluding their associated methods, information and data structures arestored in computer readable media.

Thus, it will be appreciated that a behavioral description in accordancewith a present embodiment of the invention is encoded in a computerreadable medium. For instance, each variant behavior object includes abehavior code unit implemented in computer readable code which isassociated with an input node and an output node The input node theoutput are implemented with computer readable code. The input node canbe associated with a data set type. Such variant behavior object alsocan be associated with behavior code that effects a pattern forprocessing of a data set and that references another behavior object.The reference to another behavior object can be a self-reference. Anabstract transport object can effect transport of a data set from theinput node to the other behavior code unit.

1. A computer implemented method of removing an exposer and a collectorfrom a design, the method comprising: identifying in a design a firsttransport that connects to both an exposer and a collector; determiningwhether an output of the collector and an input of the exposer havematching data set type; if the data set type of the collector outputmatches the data set type of the exposer input, then substituting inplace of the first transport and the collector and the exposer, a secondtransport and a third transport; the second transport being connected inthe design to a first input transport that had been connected in thedesign to an input of the collector and to a first output transport thathad been connected to an output of the exposer; and the third transportbeing connected in the design to a second input transport that had beenconnected in the design to another input of the collector and to asecond output transport that had been connected to an output of theexposer.
 2. The method of claim 1, wherein the input of the collectorhaving been connected to a constant value, the collector being removedand the second and third transports being connected to the constantvalues.
 3. The method of claim 2, wherein all the collectors andexposers are removed, leaving only constant values connected to thesecond and third transports.
 4. The method of claim 1, furthercomprising: identifying in the design a fourth transport that connectsto both an exposer and a collector; determining whether an output of thecollector and an input of the exposer connected to the fourth transporthave matching data set type; if the data set type of the collectoroutput matches the data set type of the exposer input, then substitutingin place of the fourth transport and the collector and the exposer, afifth transport and a sixth transport; the fifth transport beingconnected in the design to a third input transport that had beenconnected to the fourth transport in the design to an input of thecollector and to a third output transport that had been connected to anoutput of the exposer connected to the fourth transport; and the sixthtransport being connected in the design to a fourth input transport thathad been connected to the fourth transport in the design to anotherinput of the collector and to a fourth output transport that had beenconnected to an output of the exposer connected to the fourth transport.